The limit of OOP Paradigm in really complex system? [closed]

Question

I asked a question previously about Dataset vs Business Objects .NET Dataset vs Business Object : Why the debate? Why not combine the two?

and I want to generalize the question here: where is the proof that OOP is really suitable for very complex problems ? Let's take a MMO Game Engine for example. I'm not specialist at all but as I read this article, it clearly stands that OOP is far from being enough:

http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-future-of-mmog-development-part-2/

It concludes: Programming well with Entity Systems is very close to programming with a Relational Database. It would not be unreasonable to call ES’s a form of “Relation Oriented Programming”.

So isn't OOP trying to get rid off something that is here to stay ?

OOP is non-linear, Relational is linear, both are necessary depending on the part of a system so why try to eliminate Relational just because it isn't "pure" Object. Is OOP an end by itself ?

My question is not is OOP usefull. OOP is usefull, my question is rather why the purists want to do "pure" OOP ?

Answer 1

As the author of the linked post, I thought I'd throw in a couple of thoughts.

FYI: I started seriously (i.e. for commercial work) using OOP / ORM / UML in 1997, and it took me about 5 years of day to day usage to get really good at it IMHO. I'd been programming in ASM and non-OOP languages for about 5 years by that point.

The question may be imperfectly phrased, but I think it's a good question to be asking yourself and investigating - once you understand how to phrase it better, you'll have learnt a lot useful about how this all hangs together.

"So isn't OOP trying to get rid off something that is here to stay ?"

First, read Bjarne's paper here: http://www.stroustrup.com/oopsla.pdf

IMHO, no-one should be taught any OOP without reading that paper (and re-reading after they've "learnt" OOP). So many many people misunderstand what they're dealing with.

IME, many university courses don't teach OOP well; they teach people how to write methods, and classes, and how to use objects. They teach poorly why you would do these things, where the ideas come from, etc. I think much of the mis-usage comes from that: almost a case of the blind leading the blind (they aren't blind in "how" to use OOP, they're just blind in "why" to use OOP).

To quote from the final paragraphs of the paper:

"how you support good programming techniques and good design techniques matters more than labels and buzz words. The fundamental idea is simply to improve design and programming through abstraction. You want to hide details, you want to exploit any commonality in a system, and you want to make this affordable.

I would like to encourage you not to make object-oriented a meaningless term. The notion of ‘‘object-oriented’’ is too frequently debased: – by equating it with good, – by equating it with a single language, or – by accepting everything as object-oriented.

I have argued that there are–and must be–useful techniques beyond object-oriented programming and design. However, to avoid being totally misunderstood, I would like to emphasize that I wouldn’t attempt a serious project using a programming lan- guage that didn’t at least support the classical notion of object-oriented programming. In addition to facilities that support object-oriented programming, I want –and C++ provides features that go beyond those in their support for direct expression of concepts and relationships."

Now ... I'd ask you ... of all the OOP programmers and OOP projects you've seen, how many of them can honestly claim to have adhered to what Bjarne requests there?

IME, less than the majority.

Bjarne states that:

"The fundamental idea is simply to improve design and programming through abstraction"

...and yet many people invent for themselves a different meaning, something like:

"The fundamental idea is that OOP is good, and everything-not-OOP is inferior"

Programmers who have programmed sequentially with ASM, then later ASM's, then pascal, then C, then C++, and have been exposed to the chaos that was programming pre-encapsulation etc tend to have better understanding of this stuff. They know why OOP came about, what it was trying to solve.

Funnily enough, OOP was not trying to solve every programming problem. Who'd have htought it, to say how it's talked about today?

It was aimed at a small number of problems that were hugely dangerous the bigger your project got, and which it turned out to be somewhere between "good" and "very good" at solving.

But even some of them it isn't any better than merely "good" at solving; there are other paradigms that are better...

All IMHO, of course ;)