I think the point is that you are asking the wrong question.
The question is not, “Why is object-oriented programming bad?”, it is, “Why is misusing object-oriented programming bad?”.
Which is basically the same as asking, “Why is misusing C bad?”
“Why is misusing pointers bad?”
“Why is misusing a gun bad?”
Things are made with a purpose in mind.
Object-oriented programming’s purpose is to give humans a more intuitive way to think about the way they organize code. Notice that I said how to organize code, not how to write code.
While C++, for example, does have new operators and templates and etc., most of the code you write is still C. if, while, for, ++, ==, etc. compose the vast majority of the code you write.
If your name happens to be Paul Graham and you couldn’t figure out how to make use of the extra organization offered by C++ (for example) and you ended up with the example provided by japro in which trees can suddenly talk, then maybe you should go write a bunch of articles to prove to the world how bad object-oriented programming is just because you couldn’t figure it out.
Just like the guy who wrote all those articles about how bad guns are just because he knew they shoot things but not what to shoot with them so he ended up shooting himself in the head due to misuse.
From programming languages to physical objects: Use them properly.
L. Spiro
What's wrong with OOP?
Finally, I wonder, if OOP is so bad, why is it so widely used, especially in game industry (this is what I read and heard of)?Bad OOP is bad - OOP by itself isn't good or bad. OOP has many benefits when used properly, and many pitfalls when used improperly. The reason it's widely used isn't that important -- that's a question of popularity, which is often only slightly related to technical merit.
You've mis-read much of Promit's rant -- OOP is reusable, but the style of code described in the paragraph prior to stating "most of this code never turns out to be "reusable"" is not reusable.
This is the style of OOP that was popular in the 90's, which spawned Java, and which made it's way into a lot of academia (and thus onto students, to go out into the world and perpetuate tonnes of bad code). This is where you use inheritance lightly and frequently, where [font=courier new,courier,monospace]virtual[/font] is thought of as a good default option, where composition is not valued for code re-use, where free-functions are shunned, where you go looking for a "design pattern" to use, where you do nothing to avoid coupling, make uber classes with tonnes of different responsibilities, and have never heard of demeter.
This perversion of OOP is widespread in the industry, is taught to people as "OOP", who then think they know "OOP", and it does result in unwieldy, bloated, inefficient code that is unmaintainable.... but that's because these people missed the point of OOP and are simply writing bad code.
I see OOP as a collection of capabilities I can take advantage of in the language i'm using. If it makes sense to use iheritance, use it. If it make sense that a framework should use overloaded/overriden methods, do it, if it doesnt, dont do it. OOP is just another tool in your toolbox, treat it as such. Know how that tool works, and what its best used for and you'll never use it wrong. Same can be said about Declaritive, Functional, Reactive, etc methodologies. Use them when it makes sense for the problem at hand, otherwise use something more appropriate.
There is nothing wrong with OOP per se. It is simply a design methodology suited to a certain problem domain.
The problem I see however is the "OOP or die" mentality shown by various (often inexperienced) programmers.
As the saying goes "If the only tool you have is a hammer, every problems looks like a nail" or something like that...
I think the biggest flaws of OOP (or rather, how it is generally misused) are:
* The tight coupling of data and functionality. It makes sense in some cases but many algorithms are not dependant on type. This is where templates, generics, operator overloading or function overloading in general come in handy. Generally I try to put as little advanced functionality in the class as possible. If a method does not access private state or takes class instances as parameters it is a candidate for extraction.
* The strict taxonomy created by inheritance. Subclasses are disjunct sets. You can overcome this problem by either stuffing more functionality in the base class (bloat), using multiple inheritance (hard to manage, not supported in many languages) or separating orthogonal class concerns. By doing the latter you end up with smaller, more manageable pieces that don't usually resemble "your typical" OOP design.
However, there are alsosome nice things about OOP:
* Encapsulation. By defining explicit entry points into the maintained data, producing stable code should be easier.
* Interfaces. Separating algorithms from representation. Unfortunately a little expensive at least in C++.
The problem I see however is the "OOP or die" mentality shown by various (often inexperienced) programmers.
As the saying goes "If the only tool you have is a hammer, every problems looks like a nail" or something like that...
I think the biggest flaws of OOP (or rather, how it is generally misused) are:
* The tight coupling of data and functionality. It makes sense in some cases but many algorithms are not dependant on type. This is where templates, generics, operator overloading or function overloading in general come in handy. Generally I try to put as little advanced functionality in the class as possible. If a method does not access private state or takes class instances as parameters it is a candidate for extraction.
* The strict taxonomy created by inheritance. Subclasses are disjunct sets. You can overcome this problem by either stuffing more functionality in the base class (bloat), using multiple inheritance (hard to manage, not supported in many languages) or separating orthogonal class concerns. By doing the latter you end up with smaller, more manageable pieces that don't usually resemble "your typical" OOP design.
However, there are alsosome nice things about OOP:
* Encapsulation. By defining explicit entry points into the maintained data, producing stable code should be easier.
* Interfaces. Separating algorithms from representation. Unfortunately a little expensive at least in C++.
OOP moves knowledge into code. Yet code is worthless and transient, the knowledge is what matters. That is why we have file systems and databases. They outlive any language.
Interfaces[/quote]
OOP does not require strong typing or typing at all. Original definition of OOP talked about opaque messages being sent and messages not being understood were a part of definition.
The cache issues are caused by today's language's interpretation of OOP. There is precisely nothing preventing anyone from encapsulating such knowledge in OO manner. Bigger scalability issues come from incorrect abstractions, not OOP itself. Just like words aren't good or bad, it's how they are composed that determines that. Encapsulation as part of OOP only gives excellent opportunity for optimization by being explicit about dependencies - limitations are caused by mainstream languages in use today. IOC and DI solve the same problem as applicable to maintenance of software by making code transient and putting emphasis on interaction between data.
One of bigger harms which cemented fate of OOP was Java. By going over the list of 10 fallacies of network programming, they made sure Java standard library (not the language) commits every single one of them. C# is now trying to patch things a bit through async/LINQ and while decent, it's evolutionary change. If those fallacies applied to network programming, they apply to all layers today, cache, disk, network and any other hardware resource due to von Neumann bottleneck.
the real wtf here is .. geocities??? stuff is still on there? omg..
other than that, it depends a bit on the language, and it's a great tool to add and use when doing a job. but it should never be the only tool. extremism never works out well. being an oop-and-oop-only prayer is just as stupid as being an oop-hater.
other than that, it depends a bit on the language, and it's a great tool to add and use when doing a job. but it should never be the only tool. extremism never works out well. being an oop-and-oop-only prayer is just as stupid as being an oop-hater.
the real wtf here is .. geocities??? stuff is still on there? omg
Hehe yeah. I saw that page a while ago. And while he has some valid points, the presantation and rambling make him look a little bit lunatic.
Time cube anyone?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
