Why is object orientation not suitable for most scenarios?

Question

Citation maniero:

It’s the biggest problem we have in our area, and it’s getting worse: something very good is created and it serves 1% of the problems, maybe 10%, but people want to use it for 100% of them.

Citation sk-Logic:

OOP is Pretty Useless Outside of a very Narrow field (namely, agent-based Simulations).

Added to this is the hype of OOP, which was adopted by the software industry as silver bullet for numerous scenarios.

It can be said that object orientation serves (brings benefit) for very few problems.

For which scenarios/domains the object orientation serves?

Why object orientation is not suitable for most scenarios/domains?

In which scenarios/domains it is more or less neutral?

Answer 1

Object orientation helps manage complexity. Where there is no complexity it is an unnecessary tool.

Interestingly it adds complexity, so the more you do OOP the more you need OOP, it’s endemic. Of course, it may be necessary, it may be useful. The biggest problem is when you have artificial complexity, by wrong modeling, done without thinking, no time to plan and mainly understand the real problem. The developer’s job is to find a more suitable solution, not to find any solution.

Natural complexity exists in large projects, preferably with many programmers involved, or else in projects so large that they go out of control, for example in frameworks, where the project starts with who developed it but only ends with who consumes it, I think you can imagine how complex it is to manage this passage.

Everything Alexei said is true in a surprisingly good response to users that we know little around here (he needs to participate more :) ), although I do not know if answered :). OOP works best when there are different teams working on the project and understands the project as the entire solution, all the parts that are combined, up to those that come along with the language.

Doing the OO project requires you to think about what you are creating more broadly, with more details, considering more interactions, understanding the scenario. Without that understanding, it doesn’t work. One of the reasons that most of the "object-oriented" (pseudo) codes that we see out there are bad is because people don’t understand that the tool was designed to induce you to better understand the problem with global vision. Not knowing this the person is wasting his time with mechanisms that have added complexity and brought no benefits. OOP does not guarantee anything better, has to know how to do, always, anything.

And you can manage all this complexity well without OOP, only it’s not so common to use others because this was the most taught tool.

Reuse

Some say nowadays that O is not about reuse, but always has been. And in fact it helps you make things more reusable, more interchangeable, makes it easier to compose better, extend functionality, isolate certain parts, and mainly make the object’s characteristics more easily discoverable. So in OO reuse scenarios helps a lot. It’s the case of GUI. Applications that have many parts based on other parts and that in each situation need to take a slightly different shape.

Black box

OOP creates a black box, you know, it’s like you’re creating an engine and every part of it is designed by a team completely and this part only has a basic communication with other parties. Internally other teams don’t need to know what happens there (but you should understand how you use it, the consequences of doing anything, and this doesn’t usually happen in practice, which is sad). This isolates the complexity.

Many states and direct behaviors and relationships

The more complex the objects must be (many states, many behaviors) the more OOP makes sense. If objects become too simple it makes little or no difference to program otherwise, especially if this other form is still modular, which is an important feature. But industry has become attached to modularization via objects. Just don’t think I’m saying that OOP is always a big object. It also has a little bit to do with how all this relates.

Turns and moves one appears here that creates a complex object, all modular, with unique responsibilities, all right, then he says he needs to ensure that the methods are executed in specific order. Ready one did not understand what the tool is for and used only because it is fashionable.

Examples

A game It usually has a huge amount of objects with various actions concomitant, having relationships between them, and can have new objects relating to existing ones, many instances. Sounds like a good scenario, doesn’t it? For certain parts.

A ERP platform that will be customized by customers should be OO, don’t you think? A platform ERP is a framework. Not so much an internal ERP. That seems like a mistake. Unless even internally you’re practically creating a platform. But is it right? Is it worth the effort to keep something so organized, and does it cost extra for something that can be more easily manipulated by the internal team? There are cases that do and cases that don’t. Few cases have you business domains that fit so well with objects in that direction. Objects change too much, to keep flexible you have to separate everything into very granular parts, to the point that practically you have no more useful objects, you have a heap of classes that are not even real objects, at most you are creating abstractions, and OOP is not just abstraction, and abstraction you get in other ways.

Business rules

Business rules are too volatile to try to assemble objects as in GUI, for example. There is evolution in generic screen elements of your desktop or mobile, but these changes are always in small, more controlled details. In a LOB application there can be radical changes, even if the most radical ones are not as frequent. In these scenarios the change is so great that OOP ends up making no difference. To help these scenarios after finding that OOP alone did not help created other things like DDD for example. The amount of complexity he adds is so great that very rare scenarios are useful. I have seen cases of people who adopted him because it was fashionable and there was huge regret, or didn’t even realize how unproductive they had become.

But of course, you can create an abstract billet and then derive it into specific bank billets. It makes sense. Just note that this is another one mechanism than a business rule. OOP does better with mechanisms. It doesn’t mean you can’t use it as a business rule, but contrary to what a lot of people say (usually people who don’t spend years maintaining the same software to talk about if everything she did survived the time) OOP complicates maintenance, Ngessa certain things. Restructuring a closed object is more complicated than looser parts. The solution that often OOP gives is to create new versions of this object extending the original. In the long run this is terrible, it doesn’t scale and it’s generating confusion, to use this advantage of OOP starts to have crazy things like Cliente2, ClienteNovo, Cliente2019. Rarely do this, but usually the solution is not object oriented, simply the person remakes the object and goes fixing in the system to adapt to the new version.

Domains where you have broad knowledge and that will not change so much works better. To make OOP easier to stir and refactor, they create objects so small that they are practically no longer OOP, but because they still use classes they think they are OOP.

Don’t forget that OOP was essentially created for GUI. Then they thought they could use it for other things. Some got it right, some didn’t. All, if done correctly, may work, but it may not be the best solution, or it may not bring real benefits. There are no studies that indicate that OOP brings the benefits that sell, each has its perception. I passed mine. In GUI I see easy that has benefit. In several mechanisms also. GUI is mechanism.

Counter-examples

So I find it strange OOP in PHP which is composed by scripts, or its use in microservices that exist to break major problems into tiny problems that communicate through external protocols that have nothing to do with code.

Want proof that complex systems, where many people work on the project, can be done without OOP? Operating systems. Take Linux, it should be close to 100 million lines, many thousands of programmers working, can not get anything wrong, has to evolve well, and evolves a lot. Of course, there are always good programmers who move there. And that’s more important.

OOP is about mediocrity

It is paradoxical, but in general scenarios with bad programmers tend to use more OOP. In some cases consciously. It is easier for a person to engineer the solution in terms of classes and their relationships and to let inferior programmers implement the codes. But in many cases this happens by accident. There is no solution, any tool will produce a bad application.

It’s easier to manage problems of bad programmers when you have more defined objects, who don’t need to have certain concerns that other solutions require.

Teams that rotate a lot can benefit by having these objects more black box. But for these scenarios it is possible to have good solutions out of OOP.

Addendum

Since no one asks I will take the opportunity to make Agile X Waterfall which is about project complexity.

Waterfall was created in the 60s, although not formalized. The projects at that time were very small, were only a few KB. In the 1970s its most formal adoption took place within IBM and companies that reproduced the culture. It documented a lot and served as the basis for much of the "innovation" of IT, at that time still called PD. The mistake is that the projects got big and they stayed that way. Independent developers had no access to this material and used Waterfall in short iterations, all in a natural, intuitive way. This happened a lot in the 80’s. In the 90’s, the Agile guy who was a rebellion against Waterfall became fashionable. Agile is nothing more than Waterfall breaking into parts.

But almost everyone already did it. And it works when one knows how to do it. When one doesn’t know, something goes wrong. What happened was a huge sale of books, courses, consultancies to teach people to do what they already did. The creation of Agile itself is against all that speak of Agile. It has literally 4 lines, the rest is invention for industry to earn money. Advocaia de Agile is selling refrigerator to Eskimo.

That’s why I say people should care more about making organized software than doing OOP. Object orientation is only a means, not the end.

Completion

Object-oriented programming is quite different from consuming object-oriented created things.

Your over-adoption has to do with this Dunning-Kruger effect and specifically the cognitive bias.

Answer 2

The advantages of object orientation appear only in large projects.

It takes a lot of work to break up a problem into small objects-oriented pieces, because the orchestration of these pieces is often greater than their creation.

They joke that the most boring thing about Java for example is to create a Factory. Creating an object with x features is relatively easy. It is difficult to create a "mother" who would be such a factory, who should know exactly how each child should be raised, and who should know how to interact with others to bring it to life.

Now, you might be wondering, if it’s so difficult to create object-oriented pieces, why is lightning even more useful to do this in large projects? Simple,

In large projects, we have several people involved, and several teams involved. If each one makes a relatively small object, compared to the whole of the project - and here we are also talking about the boring Factories - with a well-defined scope, it takes less time to finish the project.

It is much harder to do this in a project that does not use OO, because every step of one logic depends on the other. In O no matter how you do a thing, it only matters what it provides, and what it needs.

And even more: if you need an object that has already been done in another project, what do you do in OO? Simple, vc uses the object, much easier and less prone to errors than copy-and-paste code.

Answer 3

Object orientation is a strategy

Object orientation is a strategy to assist the process of design. The SWEBOK, version 3 (here), records the "body of knowledge" of software engineering and provides details.

Like other strategies, it was not developed or indicated for "all" scenarios. Having said that, it may be interesting to observe what each strategy offers of "good" and in which scenario to use it. In this sense, there is a question in Stackoverflow itself that can help, by clarifying the differences and uses between object-oriented programming and that so-called functional (here).

Answer 4

Use of object orientation

Indeed, object orientation is not suitable for all scenarios. Depending on the size of the project, dismembering the problems into multiple objects generates more complexity than the problem itself.

I see that object orientation is placed on the pedestal and procedural is seen as something "outdated". This does not make sense, because they are different visions to do certain action. I think it’s important to be aware that nothing is unanimous, let alone programming paradigms.

Among the scenarios where the paradigm is not advantageous are:

• Very small projects.
• Small scripts for automation of some task.