Is APOO useful today?



  • I went there software engineering. SE and https://softwareengineering.stackexchange.com/questions/376731/which-ooad-methodologies-are-prominent-today what has the methodology of APOO (Analysis and Project Guided to Object) prominent today (here in Brazil there is not much, but there in the USA, it goes that... right), as in the past, in the 90s, time of method wars that culminated with the creation of the UML. Before the question was closed they said that the OO part has much less emphasis today than in the 1990s and that what is closest today is the technique of design that takes advantage of OO call Domain-Driven Design.

    I think that's right, because you don't talk about UML anymore as you were talking about in the 2000s (i.e., you don't see the job ads anymore), and the teams didn't put anything in place, the impression I have is that today at most agile development with design ad hoc.

    My question is: Is APOO useful today? Why don't you use it? Is it because you don't give the expected return? Or don't the people know? Or don't you care?

    What do you do in place? What should you do in place?

    Hard to answer? I understand, there closed by "not sure what you're asking".



  • What matters is to deliver product that meets requirements, among them that:

    • be easily usable (which involves many things, among them the right speed)
    • solves the problem correctly
    • allow evolution with tranquility
    • other punctuals.

    He has several techniques to do this, but to choose a closed one, and that he has to do everything that is in the "girl" does not seem prudent.

    Object-Oriented Analysis and Project does not seem to me to be a very closed technique in a certain aspect, that is, it does not seem to be a handbook, at least not for a book of the 80s that I have (or had) on the specific subject.

    To speak the truth to create a project and to know that it will be oriented the object seems to me a beautiful of a tendenciosity.

    Agile

    I usually say, even lecturer, that almost every conceptualization of what we use in computing was created until the 1960s and almost all the technology we use today was created until the 1970s. You have very few exceptions. Almost everything is small evolution in the way of using or recycling what existed. In my opinion, much as a marketing function, is recreated to have a new product. I see people talking about Agile today when this is very simple, and in the background it is just a matter of common sense, but people have given a way to make a lot of money with the carnival they have made.

    The https://www8.cs.umu.se/kurser/TDBC31/Overheads/L6_new.pdf It's got a lot to do with it, it was a Gold race to see who can impose his pattern and get rich with it. They didn't invent anything new, they only packed in a different way.

    UML

    Luckily a half UML who died (have people who haven't noticed it yet), it was always a nonsense (not that it serves anything, but it is no better than what already existed except one detail or another), as a tool created is unnecessary. It was the time that the industry wanted to sell such https://en.wikipedia.org/wiki/Computer-aided_software_engineering that people were talking about going to end the programmer and I laughed, even though I was an inexperienced 20-year-old boy, and I had an argument, it wasn't kicking.

    What's left? The good and old systems analysis and design, some object-oriented. Each time with new scripts of how to do, sometimes use different graphics or tools to help visualize the project, and in some cases within a given bias to make in a specific way as the fashion of the moment. Even because they do not know what to do and resort to the formulas that someone sells to them.

    Because it is no longer used

    The question states why it does not use, but lacks evidence that does not use. They probably don't use the term. If you're talking about a specific script, you can tell if you know what you're talking about. What's the option? "Meter the flake" and deliver anything? Some think that Agile is like this, some think that if planning anything is not agile. I'm sorry about those people. Nor am I going to get into the merit that some products are terrible precisely for adopting Agile, no matter whether right or wrong (when it goes wrong they say it was not the right Agile, when sometimes the problem was not that). They say that UML is Agile, being that it is something extremely bureaucratic and a normally unnecessary step that brings little benefit. To speak the truth I saw much more agile Waterfall project than Agile project using UML and other inappropriate tools.

    Conclusion

    My conclusion is that it is just not fashionable to use this term. And this is nothing different than people, even informally, sometimes scrambled a paper, making a prototype in code, in short, agile is that, is to do, is meet the demand.

    No methodology teaches to do right, is experience, it is the ability of the person to look at all, look for every detail, let nothing escape, create a new look, rethink what is finding there, understand what needs to be done, what will have of future difficulty. And what I usually say, in orientation the object is usually more difficult to do because you have to see the object and much of its relationships in a very appropriate way, while paradigms or guidelines that prey for the composition are more flexible.

    OOP

    That's why you say:

    • in OOP to every change in the project that requires a new action you have to change various objects
    • in procedural/functional you have to change each function whenever you add a new object in the model.

    Here comes the question: what is most common in real-life software projects, after initial creation, add new objects or functions to the object? So I defend a approach Hybrid. And more and more I convince myself that OOP in business domain should be very limited, it is better for mechanisms, where the programmer has more control and theoretically manages to predict more what can happen.

    DDD

    I don't know if DDD has something to do with it (by the original question in SE.SE), even if it fits into this conversation, but I've been talking to people who use and it's horror show reported by them. And usually the one who encouraged says they didn't know how to make a right, only they took the course of the guy and received certificate from him. And by my studies has a terrible thing in the methodology that I had not noticed, although I still find the legal general idea, the problem is in the details.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2