It can produce useful information here, but our mechanism does not help people understand that this information is not canonical and universal, which reflects some bias
First let’s agree on who uses object orientation. Let’s not talk about that pseudo programmer who doesn’t understand anything about OO, maybe even programming in general and some even basic mathematics and can’t even calculate a percentage, much less know how to interpret a text or problem, they can’t put together the parts of what they’re doing, look for information in a structured way, analyze it and conclude something on their own. Because these people probably won’t even read this page, or know what to do with it.
Unfortunately I think by the 90% of the people who program fall into this category, because it’s broad and it takes from the guy who should be banned from selling hot dogs on the corner, to the one who manages to deliver projects that work and to some extent are right, but still understand only vaguely what they are doing.
I don’t think there are many people who understand what OOP is, probably not even who created the term (I explain below). And obviously I’m not saying that I understand. People who categorically state that her definition is the right one should suffer from the Dunning-Kruger effect, which is different from being assertive about what she believes is right.
I’m sorry if anyone feels offended, my intention was just to put a basis of what happens on the market to justify why we got to this point, I don’t want to offend anyone, and if you felt that way, think about if you can change something because you saw it fit you, or suffer from impostor syndrome or should take the opportunity to evolve and change category. I think that people actively participating here and almost everyone who passively participates are among the not offended, or unconsciously think they are "impostors".
I’m not talking about anyone specific!
Unfortunately these days we have to do all this Disclaimer.
I will say what I agree and disagree with Victor’s excellent answer and the question and adopt a different point of view, because the question is dubious about what kind of problems she is talking about.
was a very researched paradigm and I do not believe that so many people mistake it be beneficial for a large number of uses
It wasn’t much researched, seriously, and what happens most in the world is people make mistakes, they do this all the time, they love to cheat, everyone, some more than others, at one point or another. Why do you think politicians are so bad, but they still hold power? Why does the bulk of what we consume have something bad and yet nothing changes? Why do rich people spend their fortunes on things that have little or nothing added to it other than the fact that it’s expensive? And I’m gonna stop right here so I don’t get too rough :)
requires time, study and experience to learn to model
Yes, to model, to learn the mechanisms is not that complicated. But of course the guy who does not want to learn everything well will not achieve anything. But then the problem is another, he also does not know that can’t use double
for money, cannot accept inputs without positively validating, one CPF is a description, can’t thresh or ask a question on the internet, anyway, the problem is below.
objects are a natural way of thinking
Yes, for those who think :P Okay, seriously now it is difficult to establish limits of the object and that has nothing to do with what Victor answered, thinking OOP is the hard part.
I’m talking about the Java OO, but they all have complexity when it comes to designing, don’t they? Or an OO design principle does not apply to another particular OO?
Java doesn’t have an OO, it has OO mechanisms, but the project can be done by following some schools. Java has static typing that forces certain mechanisms to function in a way. Victor covers most aspects well. Java uses a series of mechanisms that have nothing to do with OOP, and people don’t even notice.
Opacity of polymorphic abstractions
Corroborate the jsbueno that there seems to be scrutiny of the implementation of language and not of the object orientation paradigm. More specifically, at least in part, you are talking about the difficulty with typing.
Recalling that in dynamic typing languages the functions are naturally polymorphic (although not all are written like this, in static typing language also not).
To me this whole section is talking about the difficulty imposed on static typing when using polymorphism (not necessarily OOP).
The difficulty in using is a little bit if you are not using an IDE. But I don’t think the OOP problem is there, OOP precisely helps the IDE better inform the code structure.
What I always say is that people don’t understand what OOP is. She doesn’t have this difficulty because it’s common for her to neither use it, especially in the right way. Most create classes and think it’s OOP. But for the "real programmer" I agree that you have this difficulty cited.
I think that affects readability code. Everything you need context to know what will happen is less readable. I pointed out why it is common for proponents of OOP to defend legibility tooth and nail, which I even agree, I just disagree that OOP helps in this. Victor’s argument shows that it’s more complicated to know what that is.
Some may say that this affects even is intelligibility. Whatever. And in consequence the manutibility.
People who advocate OOP often sell the idea that programming gets easier and this is not true. It gives the impression that you abstract and encapsulate everything and it’s all simple. Hiding concreteness has its drawbacks. I love abstractions, but when used in excess only puts more cognitive load and hides relevant points. I know some people will defend that with philosophy. I love philosophy, but when it comes to doing the project it needs to be with rice and beans (I know you’ll get it wrong, but whatever).
People complicate too much what can and should be simple.
Simulating polymorphism in a structured language
With branches (if
, switch
, etc.) you do polymorphism, not just simulate it. Not in the way people usually refer to polymorphism, it’s true. The problem is the same.
There’s nothing wrong with doing that unless you have a reason not to. Maintenance can complicate if you need to add behaviors, this form leaves no cohesion. But it is not any project or any specific problem that needs this whole cohesion. Cohesion has harms as well. I am not advocating the use of this mechanism, just making it clear that it has utility and not use it where it should is as bad as using it where it should not. I see a lot of mistaken use because one only sees traditional polymorphism as correct.
The use of pointer to function has even more to do with functional programming.
These concepts are more concrete, which is always easier to understand.
OOP abstracts the mechanism and makes it more difficult to understand what is occurring. Even if the person says no, even for himself, it is common for the person to see it as magic.
Double-Dispatch
I agree and find one of the biggest problems of the whole mechanism. Enough to disqualify the use where it should not.
It’s too abstract an example for me to say, but it’s very common for this problem to arise when you try to model something that doesn’t actually exist, when you try to use OOP where it doesn’t fit, maybe a relationship would be more appropriate.
Often it goes unnoticed
My perception is that this occurs too much in the use of OOP.
Here comes the problem I talk about, the person is so blind to using OOP for everything she can ignore that has easier ways to solve the problem. The relational model is usually easier for people to understand. I don’t know why, it needs to have a Pedagogy.SE para gente perguntar perguntar.
If I’m not mistaken elixir fix this, but pay a price.
Multiple inheritance of implementation
I see this as an implementation problem, which is simpler in dynamic languages.
I’ve discussed this several times with a lot of people, a lot of the OOP complaint is actually about static typing.
There are several ways to have multiple inheritance. Some languages do this too generically (C++ cof cof), others may restrict too much, and it is rare, if any, languages that have everything you need to function (abstract classes, interfaces, traits, mixins, roles, protocols, delegations, extensions, attributes (I’m not talking about fields), etc..).
In fact people don’t quite understand what to inherit, when to put things together, what is a mechanism and what is a business rule, what is the business limit of that object, how it can or cannot be extended, why not extend what could because of optimization, Just to name a few things. People don’t understand ontology and taxonomy. Not that this is irrelevant in other paradigms, but in OO is quite important.
The project starts well, with time it begins to be a lot of gambiarra, because one did not classify and named things right. Ah, but there’s the miracle Refactoring. Um, it seems to me that these people have only worked on small, short-term projects or that they are very statically defined. I know who talks about these things and has worked on dozens of times more projects than me in a third of the time I have profession. I don’t know if they understand what it’s like to keep a big project long-term. There’s no time to take care of hundreds of projects when you have one this complicated. And to solve this there are people complicating the projects even more, but if you follow the standard recipe you’ve done before, everything is solved and it seems that the person works a lot, productivity measured in Klocs.
I’ve seen people have to change the system almost completely because of this. This is OOP?
The problem I see is that it is difficult to define what is what. Of course you need to understand the mechanism as well. The point is that if you know what you’re doing well, you can make good use of other paradigms like modular, which is simpler and more organized.
OOP doesn’t make people create good projects magically, OOP is just the tool. Just because you have water, a refrigerator and a saw doesn’t mean you can do this:
Simple inheritance of implementation
I agree 100%, especially the last sentence of the first paragraph. And this is a relational and modular model and not OO.
Much of the problems we deal with today have been created because they have started to make inheritance where they should not, and in many cases should not. Unfortunately people don’t see it, they don’t understand what problems it will have in the future by having this coupling.
And guess why it’s often no problem? Because the problem was too simple and/or static, and OOP was not needed there.
Crosscutting-Concerns
It is a limitation of OOP and other paradigms. The functional handles it better with its own limitations, metaprogramming in its various forms as well, as the modular but less because it ends up being a middle ground, but it has a problem, it is worse defined than OOP.
aspect-oriented programming was not well accepted because it has a strong negative side as well: it causes the code to acquire in it behaviors that are not expressed there and that are encoded far from the point where they are executed, without there being any clear indication for such a fact
OOP too and was very well accepted.
But it is a fact that it does not deal well with the modeling of the real world. That is why some people nowadays deny that this was the goal of the paradigm, even being full of material from the past saying this. So what is the advantage of using OO? Reuse? There are those who deny too. And can only reuse well if you do not try to make objects that take care of everything.
This is the biggest limitation of the paradigm, taxonomy needs to be perfect to work well, but this is difficult or impossible.
Focus on objects and not on actions
There it says that the languages that said OO have surrendered to the functional. They are neither one thing nor the other, only allow something in this line. Essentially these languages are imperative.
People focus on actions and it seems hard to understand that this is not OO. OO is data structure.
Inextensibility of classes
There are several solutions to this. In fact I believe that this limitation is not OOP, as far as I know pure OOP requires that classes should be extended. But there must be controversy about this.
However, the mix-in still has a downside, which is to be a behavior assigned to an object that does not appear in the code of the class corresponding to that object, being located outside the class where it is applied (and possibly somewhere far away from it and quite difficult to be determined).
This is a criticism I make, proponents of OOP tend to destroy cohesion by wanting to put everything together that is separate. The procedural/modular/functional tends to allow these compositions in a much simpler way, greatly facilitating maintenance and simplifying creation. The error charges you much less when everything is more granular.
In dynamic languages this is often much simpler, even in OOP.
There was presented a limitation of Java. Although the existing solution in other languages is also not well oriented to object.
Dependency injection
I agree. And this complication is something that most people don’t quite understand, and they don’t know when to stop doing this. It’s very common to violate KISS and YAGNI to be "OOP".
There are some questions there that are very difficult to answer. In fact almost everything, when modeling objects is difficult. The worst is that people learn that the answers to this are wrong recipes. They teach in bad abstract examples and people fail to apply in the real context properly.
They often say do DI to facilitate the test. Then you will see the tests and are a heap of bad engineering, testing the obvious and leaving aside what matters because the person does not understand the difficulties that it will have with that object. That’s why TDD doesn’t work. And the unit test done afterwards only solves regressions... if the project remains firm in its initial philosophy of quality, which is rare in long projects that are not products for other developers to use (even these are not always so).
Greater complexity than other paradigms
I agree with everything before Bullets. Too bad people don’t understand that OOP is modeling.
Few people reach the level of using OOP well, and many think they have (I’m not talking about aloprados). I didn’t arrive after 30 years doing this because I don’t do the same project every time. Once again, you learn to do better when you’ve made a mistake on a number of projects. Whoever did several projects, due to their size, probably worked on things that OOP was not so useful. There are exceptions.
Making a form using the classes in your GUI is not object-oriented programming, it is using the object-oriented programmed. The same for MVC and others frameworks. And yes, the greatest utility of OOP is to build frameworks. My experience in business systems is that almost always it has less utility than people imagine.
Already looking for studies that indicate that OOP has these qualities that propalam and did not find. This proves nothing, unless you have no proof that OOP is so much better. It’s all perception. Mine is the one I just said above.
Done wrong, and this includes using OOP where it shouldn’t, no value delivery.
Some people complicate the code just so they don’t break the rule that says switch
is the devil’s work.
I’ll wait to see if Victor can tell me what’s wrong with PessoaJuridica extends Pessoa
. I think normal, almost all inheritance should be on top of abstract class, interface or something, there serves only as taxonomy and/ or reuse. I find it strange Cliente extends PessoaJuridica
that triggers cohesion.
In fact "pure" OOP does not like primitives. That’s why I think OOP is bad, it’s academic and not engineer stuff that uses what is most suitable for the problem.
In OOP what I see most is the use of Copycat.
The fact is that OOP is taught all wrong, and it has become almost impossible to teach right, because "no one" agrees with what OOP is. This further diminishes its usefulness, making it difficult to communicate. And the biggest mistake is teaching that OOP solves everything very well and ignore other paradigms.
Extra complexity in the representation of abstract concepts
So it seems to be more of a critique of abstraction. It’s a problem when you say you can only do it in an abstract way. Modeling things that change is complicated. Not complicating what can be easily changed is more difficult to see, then one goes in the default and complicates everything.
Note that all products used by us devs uses OOP to some extent and goes into concrete where it is best.
Of course, everyone can have the opinion that this is not a valid criticism, I validate it, until the day they prove to me that it is not valid.
Object-oriented programming has inferior performance
The problem is not the mechanism, is the model. If you exaggerate you get problems yes. If you need the maximum performance is something else. Functional has problems too. When performance matters, other paradigms can be more useful. Metaprogramming can help in abstraction at no cost. It is common for OOP to end up hiding complexities that only turn slow too late. Sure, it’s design mistake, but OOP helps to have it.
The problem with Object-oriented Languages is they’ve got all this implicit Environment that they carry Around with them. You Wanted a banana but what you got was a Gorilla holding the banana and the entire Jungle.
-- Joe Armstrong
Over specification without generic types
Curious that a good OOP modeling is to make use of genericity and not OOP. It is an OOP problem in static typing. And OOP (not all definitions) preaches inheritance and not genericity.
Lack of a canonical definition of object-oriented
If each one understands in a way is a complicated paradigm to follow. It’s hard for people to understand each other in projects, first you have to learn what the team’s OOP is, and today the team can be the world.
If people don’t even know what OOP is, it’s hard to use and evolve in the paradigm. Every hour you are influenced by something different, you don’t know if what you are taught applies to the by-product you are using. This is one of the biggest problems of the paradigm. A lot of the mistakes made in it are because of this.
The described pillars is what I think, but the creator of the term does not think so, although he himself has already said (or almost so :) that should have called that message guidance or server-oriented and says that chose the term mistakenly.
I have been wondering about what encapsulation and abstraction is, I have the impression that I have always misunderstood, and a lot of people too, so they teach wrong and everyone learns wrong. I publish something the day I’m right (I started doing it).
Some people say almost the opposite of these things, so it’s a problem. It’s hard to know if you’re doing it right if there’s someone who tells you to put everything in class, and who tells each class to do just one thing.
Victor objected in comments on his answer that inheritance is something inherent in OO. I live doing these things, it’s complicated to deal with something ill-defined.
If it only has one of the three pillars, is it OOP? Some people say yes and say it’s encapsulation, and I think it might be, considering that this is just bringing it all together in class. The only one that is exclusive to OOP is the inheritance.
Interestingly, it has a dynamic typing language that has subtype inheritance, I’m not going to name names, but it starts and ends with P :P :D
Anemic model
It is a modular model that makes maintenance much easier. There are people who have no problem with cramming everything into one class, or don’t see it as a problem, even if it is, or make relatively static systems, as I said above.
It doesn’t matter if it’s anemic or not, sole responsibility matters. In other paradigms it’s easier to have it, some are automatic. Hitting the "size" of the class is very difficult. And is worth everything you said throughout the text.
100% OOP encourages rape DRY, and there’s a strong movement towards this lately. People are going crazy :)
Cohesiveness it’s not about putting it all together, it’s about putting together what needs to be together. Not even talking about classes. Being cohesive is important, being encapsulated to the extreme not.
Cohesion depends on context. How to model this in OO? Simple, making modular/functional or even procedural. A lot of people do, but think they are doing OO (remember, I’m not talking about noobs).
Since we don’t even know the definition of OOP, we don’t know the details of what is cohesive for OOP. What I know is that cohesion is fundamental, and this has existed in computing for over 50 years, before OOP and before the term software engineering existed. I’m talking about the term using in our area, in others it’s secular, or millennial, I don’t know, ask ptlang..
Spreading things without discretion and putting everything together without discretion are equally bad.
Difficulty writing a compiler
Yeah, it doesn’t matter.
It is only good to make clear that more modern languages (Rust, Go, Erlang, etc.) are not adopting OOP explicitly, do not encourage it, and the older ones are moving a little away from the paradigm, even if they deny it. This is true for Java, C# and mainly C++. The languages that bet everything on the paradigm were not successful. Alias Alan Kay thinks Lisp is the best language there is and she’s not OOP, she doesn’t have anything people say about OOP :)
Other problems
Has problems with competition. No room to detail.
The biggest problem is the difficulty in modeling, it’s not so much OOP. It’s that OOP requires doing right. When asked about learning OOP for Alan Kay, he replied with a book that does not teach programming. I always talk, the problem is that people can’t sort things out, and that’s fundamental in OOP. So it brings together different things. And we deal with problems we don’t know, or we’re repeating what we’ve done before, which is not a very noble task.
I just don’t like the book statement so much because almost nothing we program works like biology. It gets the wrong idea. Hence comes a lot of bad example of how to model OO.
If people are bad at ontology, something that makes them good at it is a invitation to disaster.
It is only easy to understand a code written well O if it was you who wrote or is in a language very well dominated by the team.
OO inhibits creativity, because it has to follow certain patterns to make everything work. OO works better to do recurring things. I won’t even talk about DDD that is OO in the worst form (the idea of DDD is good, the implementation adopted is one of the most terrible things I’ve seen in computing).
SOLID is an interesting case. Is he or is he not OOP? If you follow everything correctly you will be doing modular/functional programming and nothing in it is unique to OOP, in fact some OOP things are not in SOLID. The impression I have is that he’s opposed to OO. If this is true, and of course I think it is, it would be another case that needs to get out of the purity of the paradigm to get what it wants. And you need to know all this.
The Difference between people who like OOP Languages and These people
are that These people are Pioneers who are Actually solving Huge
problems in computing; whereas the designers, supporters, and
implementers of OOP Languages Waste all their efforts on Aesthetics or
trying to Prevent a strawman Idiot from Doing idiotic Things.
-- Joe Armstrong
Item 4 of the last objection is the most important.
If you search for OOP, OOD or word that indicates the same thing along with flaw, sucks, evil, bad, problem, misuse, and similar things will find a lot of stuff, most make sense.
Completion
I think there’s a lot of evaluation of implementations, of languages and not of the paradigm in Victor’s response. Apparently the answer indicates that it does not matter to be OOP, it is a language that is said OOP can do everything even through other paradigms. I may have misunderstood. But it is a fact that this indicates that pure OOP does not work.
OOP does not solve all problems and adds new ones. In its pure form it requires doing very impractical things and inefficient codes. It requires things that most people are not qualified to do and done wrong it causes more problems. Whoever created the term also thinks that problems are too complex and need an understanding that people do not have, and they cannot be solved in isolation how people want it. I understand that he knows that OOP is not all this, the problem is the people who think it is.
There are two groups of people: those who are distancing themselves* of OOP (or have already been distant) even if they do not realize it, and those who are sticking themselves in the paradigm hole more and more. The good news is that if you have this kind of attitude most of the problems we take care of don’t cause a lot of difficulty nowadays, because the problems are too small and too static to cause.
*Distancing isn’t abandoning, it’s using where you need it.
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.
Phrases from excellent programmers (almost everyone) who do or have done important things by hitting OOP, at least the way people use it. They seem empty sentences, but if you look you will find the context where they were said and almost all have concrete arguments behind the phrase.
Read the comments of the question, AP found more interesting things.
I like the GRASP, not everything, but the basic idea, because if you do all those things, you run away from the central idea of O. At least it’s just a guide line and it says that you should do what needs to be done to achieve a general goal. It doesn’t mean much, but it’s better to have "rules" that need to follow purely because otherwise you’re a cunt.
If you follow all the rules you have invented and keep inventing (OO has new rules almost every day :) it can work. If you follow a series of rules in other paradigms you also have a great chance of working, often more, only these rules were not disseminated, perhaps because they were created before the computation "explode".
As a curious note is to see the irony of Rob Pike, the creator of UTF-8 and this part is important in this sentence, saying that OO is the same as Roman numbers.
Object-oriented Programming is popular in big Companies, because it Suits the way they write software. At big Companies, software tends to be Written by large (and Frequently Changing) Teams of mediocre programmers.
-- Paul Graham (the whole text is interesting)
It is not OOP that is Broken - we just Haven’t Figured out (after over
40 years) how best to develop with it
--Oscar Nierstrasz
Computationally there is no limit. So is functional or even Turing machine-based. There is limitation on maintenance and readability, however
– Jefferson Quesado
@Jeffersonquesado Being the languages underneath all Turing-complete, in fact there is not. But do you mean that other paradigms are easier to maintain and more readable? Can you elaborate?
– Piovezan
I agree with most of you, I disagree mainly with
Mas foi um paradigma muito pesquisado e não acredito que tanta gente se engane em ele ser benéfico para um grande número de usos.
. People are using things the wrong way (the human being loves to deceive himself, he does it all the time, essentially everyone). It is useful some number of cases. And it has not been so studied, and where it has often shown that it is not all this wonder. If it were well studied people would agree on its definition. Neither do they know. So which OO are you talking about? :)– Maniero
@Maniero I’m talking about the Java OO, but they all have complexity when it comes to designing, don’t they? Or an OO design principle does not apply to another particular OO?
– Piovezan
Piovezan, unfortunately I cannot elaborate much = I have informal experience on the subject, very opinionated things or else I can’t even express my intuition on the subject in words
– Jefferson Quesado
@Maniero
e onde foi muitas vezes mostra que ele não é essa maravilha toda.
Could you draw up that part?– Piovezan
@Maniero researched and saw that OO failed to reuse large-scale commercial components although I can’t tell if this was the original paradigm proposal. In addition there seems to be a lack of empirical evidence in its effectiveness, some say that yes, others who nay and nay. With these remarks I think it kills the subject.
– Piovezan
@Piovezan I’m writing a reply.
– Maniero
@Jeffersonquesado I’m only going to give opinion :P, based on my experience.
– Maniero
@Piovezan This story that OO fails to reuse large-scale commercial components seems to me to stem more from social, administrative and organizational problems than from technical ones. There is difficulty in reuse mainly because many people program anyway to put out fire, whether for lack of competence, time, resource or whatever, and possibility of reuse ends up being in the background. Moreover, in many companies that develop software, departments and teams often turn into fiefdoms that share little code with others.
– Victor Stafusa
@Victorstafusa This is an idea that you would no longer need to write code, which would simply buy ready-made components made by third parties. I had until the time of J2EE, if I’m not mistaken I have an old Java magazine that quotes this. From hitting your eye at the idea I see that would not avenge, there is always something that needs to be customized, can not apply the general case at all. Library reuse works at best.
– Piovezan
@Piovezan This reuse component market was a marketable idea propagated by EJB2 proponents and never came close to materializing. She’s overly optimistic and simplistic for forgetting the obvious factor that software is complex and undergoes changes and that business rules are highly specific and not at all generic, and that’s independent of the paradigm. Something that is slowly supplying this idea is the use of webservices/Apis either via SOAP, REST or whatever. However, starting something like this to say that OO failed to provide this reuse is a tremendous exaggeration.
– Victor Stafusa