Arguments Against Oop

Summary of Criticisms Against OO

As agreed in AcceptableCriticismOfOoOnWiki, below is a list of criticisms raised against ObjectOrientedProgramming. The opposing twin of this topic is BenefitsOfOo.

Note that not every critic will agree with all of these, nor will all OO proponents agree with all the characterizations of OO given here. This is simply a collection of criticisms put forward. To keep this page clean, please put debates in the sections below, rather than embedded in the list itself. (See PageAnchor "replies") I moved the longer ones below, but left some short ones in place. [EditHint: somebody rearranged the replies into a single topic for pro and con replies and it's now very confusing and very long. (I'm angry about it.) Needs a rework.]

Two themes tend to stand out: artificialness and inconsistency. OO is based on some ideas that are catchy on a small scale or in toy examples, but they don't scale to the real world well, requiring many layers of indirection to work around their limits. Lack of consistency makes it harder to understand and navigate OO designs and study OO in general. Every OO modeler ends up modeling their own head, so you have to learn a new head from scratch each time you encounter a new OO application.


Ways in which OO allegedly violates OnceAndOnlyOnce:


Quotes

Quotes and articles about the harmfulness of OO: http://harmful.cat-v.org/software/OO_programming/

A quote from a blog that is not directly about OOP, but makes a reference to it. Source: http://www.joelonsoftware.com/articles/APIWar.html

"A lot of us thought in the 1990s that the big battle would be between procedural and object oriented programming, and we thought that object oriented programming would provide a big boost in programmer productivity. I thought that, too. Some people still think that. It turns out we were wrong. Object oriented programming is handy dandy, but it's not really the productivity booster that was promised."

Nice quote, but as an argument against OOP, it's a classic ArgumentFromAuthority.

(Moved further discussion to LinusTorvaldsOnVisualBasic)


Binding Behavior to References (BBR)

[sub-topic being refactored]

Of course, OOP techniques - binding behavior to references - can be implemented in any TuringComplete system (and even many not-TuringComplete systems), rather than just OOPLs. Appealing to that doesn't change the relevant facts; it only says that you can do OOP without a dedicated syntax via a framework and SelfDiscipline.

And binding behavior to references existed long before OOP. If anything, later languages *limited* the binding to supply "discipline" above machine/assembler address pointer spaghetti.

What? Do you mean before it was called OOP? Because many people would argue that early use of OOP techniques began with binding behavior to references. And what any 'language' or 'syntax' does is provide some discipline to remove need for SelfDiscipline. But 'BBR' was listed as a 'technique' and not a definition of OOP; the above should have read "OOP techniques - such as binding behavior to references - [...]". OOP means having references to program elements (NygaardClassification), having behavior (including access to state) associated (polymorphically) with these references (rather than injected by the holder of the reference), and the ability to communicate references.

We both seem to agree that OOP at least attempted to introduce discipline to BBR. But this would imply that BBR is not by itself "OOP". OOP is an approach to trying to tame BBR. The "problem" is managing them through navigational paths (OO) rather than relational and/or sets, not the mere existence. In other words, I don't like the way OOP manages the references, but am not bothered by existence of them by itself (if used appropriately). -t

Agreed. Related: the 'no composer' argument at the top. The need to "manage" references in OO is painful, and evil. I prefer my OO mixed with a healthy dose of FP + LogicProgramming + DataflowProgramming, along with an object-configuration builder to build large object configurations declaratively (no assignment operations, no managing order-of-operations). OOP has, without a doubt, many problems. That's true for any single paradigm.

(Moved rest of discussion to ScalingOopDiscussion.)


See also OopArgumentsDebatesAndDiscussion, OoLacksConsistencyDiscussion, OopNotForDomainModeling


CategoryOopDiscomfort, CategoryObjectOrientation
SeptemberZeroNine

EditText of this page (last edited May 17, 2013) or FindPage with title or text search