The case against OOP?

[iago]

http://www.geocities.com/tablizer/oopbad.htm

Personally, I'm a fan of procedural programming. That being said, I don't necessary agree with all (or a good part) of that article. It's still interesting to skim through, though.

(And next time somebody asks me why I like C more than C++, I can point them there :D)

[Rule]

After having formally learned OOP, I switched to doing procedural programming over the last 5 years..... the programming aspects of my work are usually minimal -- so I'm not having to organize a large project.  It just seemed way faster for me to type out my ideas in say, C, than C++ (but I sometimes did use C++ libraries so that I could be lazy about the order of declarations, etc).  There was also the mild benefit of C code being more efficiently run than C++.

But for huge projects, OOP always seemed like a more appealing paradigm.  It's a way of organizing your thoughts that seems to minimize problems (e.g. debugging time, re-use of code, etc.) in the long run.  This is why I had planned on re-familiarizing myself with C++. 

Edit:

I read through a few sections of the article.  From what I read, there is some interesting speculation, like the GUI-OOP relationship.  But that isn't really a criticism of OOP per-se, and it is lacking in convincing references or examples.

And then he engages in similar rhetorical tricks that he accuses OOP proponents of using.  For example, the communism analogy was somewhat weak, and very transparent.  If you're trying to convince a US audience that anything is bad, you'll usually do well to associate it with communism or socialism (as though pure capitalism is flawless).  And the analogy doesn't work on many levels.  They are obviously completely different ideologies... "apples and oranges".  And the idea that they were both good in theory and bad in practice is questionable, and isn't argued -- rather, it's just stated.  Even if it were true, that's a vague superficial connection you could make with many ideas; why choose communism? So that part seemed contrived and unconvincing...  it made the author lose a lot of credibility in my opinion.

But I haven't read through the whole thing yet :P.

[Chavo]

I really have no problem switching back and forth between the two.  I use OOP for Java/.NET applications because it suits the framework very well and seems intuitive to me.  Conversely, I use procedural programming when writing Assembly or C applications, especially for embedded devices/microcontrollers.  I've never had an issue with mapping database schemas to an OO structure like the article suggests but maybe that's just my choice of design.

sidenote: has any noticed some random timeouts/connect issues to x86 lately? I'm not sure if it is my work's proxy or not

[MyndFyre]

sidenote: has any noticed some random timeouts/connect issues to x86 lately? I'm not sure if it is my work's proxy or not

Yes, I think iago's server is wonky.

I generally favor OOP; I'm a big advocate of domain-driven design, and I think it's hard to achieve that if you're not modeling your domain objects.  I generally try to take an object-oriented approach whenever I have to work in a C environment (structs hold data, and functions that would be "member" functions take a struct pointer as the first parameter). 

Generally, OOP works to limit the amount of complexity to which you're exposed at any given time.  This is good from a cognitive perspective because you only have a finite amount of brain resources with which to work.

I find the author's argument of "protocol coupling" to be weak.  Good OOP programmers will emphasize the decoupling of interfaces and separation of concerns, building objects in layers, and preventing that issue.  But, OOP, like VB, allows for a greater number of people, some having a lower learning curve than others.  Most often, code that is tightly coupled is written in such a way that it looks procedural.

I also find this to be a weak argument:

Often one does not want to travel through trees to get stuff that does not relate to the tree. (File directories also often suffer from this flaw.) Relational thinking is more adaptable this way because it tends not to say that one relationship is more important than another; thus, less artificial relationship favoritism.

Relational database thinking still models this relationship; if you have an invoice_header entity, you still need to use its ID to find its children.  And the argument that you can't use ad-hoc queries is bullshit too; you just need to model the behavior.  Often, OOP programmers don't like to just allow users to free-form query at will because it has the potential to break the database integrity or something along those lines.

[MyndFyre]

Skimming more through this I ran into:

Furthermore, there is very little research on whether non-OOP languages can be used such that reuse and flexibility can be increased to the same levels as properly-used OOP.

When I was a budding young programmer I read the original Code Complete, which I consider to be an authoritative book on the topic of software construction.  It deals with a lot of different paradigms, and the entire book is based on studies.  Everything in the book is based on either a case study or an academic study.

I don't see ANY sources cited in this guy's work, especially when he makes these kinds of claims:

[Camel]

I don't see ANY sources cited in this guy's work, especially when he makes these kinds of claims:

I think this image serves better as a description of the article than it does to illustrate his point.

He obviously has never heard of a design pattern, since there are simple solutions to every single one of his claimed flaws in OOP.

[Camel]

Every time I look back at this article, I find a new reason to be outraged that this person has a right to express his opinion.



What, exactly, is the basis for this argument? The curves seem generally reasonable, but fail take in to account the most fundamental assumption of OOD: the larger the project (more accurately, the more possibility for reuse), the better OOD is. There is no "typical" size for a project. Firefox is enormous, and cat is tiny. Firefox would benefit substantially more from OOD than cat, and this graphic is meaningless.

[rabbit]

You guys should get together and write up an article called "The case against the case against OOP" and publish it somewhere.

[iago]

What, exactly, is the basis for this argument? The curves seem generally reasonable, but fail take in to account the most fundamental assumption of OOD: the larger the project (more accurately, the more possibility for reuse), the better OOD is. There is no "typical" size for a project. Firefox is enormous, and cat is tiny. Firefox would benefit substantially more from OOD than cat, and this graphic is meaningless.

I believe that's exactly what he's saying -- that OOP is great once it hits its sweet spot (large programs).

I don't see ANY sources cited in this guy's work, especially when he makes these kinds of claims:

Lack of sources is the biggest thing I noticed when I looked at some of it. I agree with some of his points, and disagree with others. In either case, it's an interesting (and different) viewpoint.

sidenote: has any noticed some random timeouts/connect issues to x86 lately? I'm not sure if it is my work's proxy or not

I've been noticing it off and on since I changed ISPs. I asked several times if anybody else noticed any issues and nobody ever came forward, so till now I was assuming it only affected me.

I'll open a ticket with them at some point. I assume it's line noise or somesuch -- it's DSL-based.

[Camel]

Firefox would benefit substantially more from OOD than cat, and this graphic is meaningless.

I believe that's exactly what he's saying -- that OOP is great once it hits its sweet spot (large programs).

I don't think so; most of the reasons he give are based on the assumption that good OO engineers are hard to come by.

Many OO books and even some OO fans suggest that OO only shines under fairly ideal conditions. These conditions may include:

• Sufficient training and mentoring
• Sufficient incentives for long-term planning and/or good OO (see Planning article)
• Sufficient understanding of the domain/task
• OO-friendly database system
• Low employee turnover
• Good code viewer/editor tools
• Sufficient budget for good planning
• Good project management

That's a very dated assumption; good OO engineers are just as easy to come by as good procedural engineers these days. You can't get a CS degree these days without rigorous OO study.