Is APOO useful today?

Question

I went there on Engineering.SE software and asked what has APOO (Object-Oriented Analysis and Project) methodology prominent today (here in Brazil there is not much, but there in the USA, will that... right?), as had in the past, in the years 90, time of the method Wars which culminated in the creation of the UML. Before the question was closed they said that part OO has much less emphasis today than in the 90s and that what is closest today is the technique of design which takes advantage of the Domain-Driven Design.

I think that’s right, because there is no more talk about UML as it was in the 2000s (I mean, you don’t see it in the job ads anymore), and the teams didn’t put anything in place, the impression I have is that today at most we do agile development with design ad hoc.

My question is: APOO is useful today? Why not use it? Is it because it does not give the expected return? Or the staff does not know? Or does not care?

What is done in the place? What should be done in the place?

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

Answer 1

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

• is easily usable (which involves many things, among them the right speed)
• solves the problem correctly
• allow evolution with peace of mind
• other punctual.

There are several techniques to do this, but choosing a closed one, and that has to do everything that is in the "little manual" does not seem prudent.

Analysis and Object-Oriented 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 little manual, at least not for a book of the 80’s that I have (or had) on the specific subject.

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

Agile

I usually say, until I speak, that almost every conceptualization of what we use in computing was created until the 1960s and almost every technology we use today was created until the 1970s. There are very few exceptions. Almost everything is a small evolution in the way of using or recycling what existed. In my opinion, much in terms of marketing, it is recreated to have a new product. Today I see people talking about Agile when it’s very simple, and it’s really just a question of common sense, but people have managed to make a lot of money with the carnival they made.

The one from warfare of methods has a lot to do with it, it was a gold rush to see who can impose their standard and get rich with it. They have not invented anything new, only packed in a different way.

UML

Luckily UML kind of died (some people didn’t realize it yet), it was always silly (not that it serves for nothing, but it is not better than what already existed save one detail or another), as created tool is unnecessary. It was the time that the industry wanted to sell such case tools that people said that I was going to break up with the programmer and I laughed, even though I was an inexperienced idiot 20 years, and I had an argument, it wasn’t a kick.

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

'Cause it’s not used anymore

The question states why they do not use, but lack evidence that they do not use. They probably do not use the term. If you’re talking about a specific script you might be able to talk about if you know which one you’re talking about. What’s the option? " Stick the kettle in" and deliver anything? Some think Agile is like this, some think that if you plan something is not agile. I’m sorry about those people. Nor will I get into the merit that some products are terrible precisely because they adopt Agile, no matter if right or wrong (when it goes wrong they say that it was not the right Agile, when sometimes the problem was not even that). They say that UML is Agile, and it is an extremely bureaucratic and usually unnecessary step that brings little benefit. To tell the truth I saw a lot of Waterfall project more agile than Agile project using UML and other inappropriate tools.

Completion

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

No methodology teaches to do right, is experience, is the ability of the person to look at the whole, to look for every detail, not to miss anything, to create a new look, to rethink what is found there, to understand what needs to be done, what will be difficult in the future. And what I usually say, object orientation is usually more difficult to do because you have to see the object and most of its relationships very appropriately, while paradigms or orientations that value the composition are more flexible.

OOP

That’s why you say:

• in OOP every change in the project that requires a new action you have to change several 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, to add new objects or functions to the object? So I defend a approach hybrid. And more and more I am convinced that OOP in business domain should be very limited, it is better for mechanisms, where the programmer has more control and theoretically can predict more what can happen.

DDD

I don’t know if DDD has anything to do with it (by the original question in the SE.SE), nor does it fit into this conversation, but I’ve been talking to people who use it and it’s a horror show reported by them. And usually whoever pushed it says they couldn’t do it right, only they took the guy’s course and got his certificate. And from my studies there are some terrible things in the methodology that I hadn’t realized, although I still find the general idea legal, the problem is in the details.

Answer 2

@Maniero’s response was perfect, I’m just including a simple observation, which I read recently in an article and complementing with my words:

Currently, requirements are changing very fast, making it impossible to perform a requirements survey, process mapping and documentation of them in a timely design time. With this, a large part of the projects is using "Agile", even without even having the notion of what it is, basing all the development on the user’s stories or simply the process described by it. The big problem is that, the user’s story is limited, because the user does not even know what he wants, or the mapped process does not reflect reality, or even there is no defined process, generating several changes in the rules of the systems after ready, which can have a very large impact on Cost X Time X Quality of the project.

A 1-month project, if there was a requirement survey and mapping of processes, might take 2 to 3 months, depending on the complexity, making it unviable for business strategy. The conclusion of Mr @Maniero describes well.

"And this is nothing different than people, even if informally, sometimes scribbling a paper, making a prototype in code, anyway, agile is this, is to do, is to meet the demand"

Answer 3

APOO is a tool. What is the intended use?

APOO is a way of seeing a problem and also seeing/designing a solution. Concepts such as class, inheritance and various other objects-oriented instruments are used to model, record and analyze this problem, as well as a proposed solution (code).

If, even today, there is constant publication of books about object orientation (be it analysis and/or design), as well as books about object-oriented languages, as well as the development of object-oriented languages, then I understand that there is evidence that APOO has a space.

This cannot be confused with a suggestion that one should make use of APOO. Its context should guide the choice of strategy to be adopted for both analysis and design. In other words, given that analysis and design are not optional, the question is how you will do this and, among the possibilities, is APOO. Additionally, if the software to be built, for example, is part of a critical system, then you will have to consider a formal development method instead of conventional APOO.

In short, there is no way to make a prior choice. Among the analysis and design strategies, you will adopt a compatible with your context, may be APOO, may not be.