Why is the object oriented model so occupying/monopolizing?

Question

Don't get me wrong - OOP currently is the best thing to structure large code bases.

But why do people try to stuff anything into an OO view?

For example: each text book about OOP contains an "introducing example" that tries to express a small view of our real world in an OO inheritance and composition and aggregation construct. And - meanwhile - we all know that it never results in the almighty OO construct that the OO model itself promised! The authors just created an illusion.

My personal opinion is, that OO is nice to structure code, but it is not suited to represent real world data and its relations. IMHO the relational model is superior, probably any other model is superior.

In OO design it became practice to recommend composition over inheritance - whenever possible. So that mighty looking model of an all-inheritance-based-world-of-objects thing that first class books suggest is just an illusion. So, OO itself may be an illusion? And current composition-centric OO models are nothing more than plain data structures with some standardized syntactic sugar - that's not much different than in pre-OOP approaches.

Another example: imagine a really f***ing complex model of our real-world. Besides anything else, there are stone blocks and humans. In an OO model, humans are mammals are animals are organic lifeforms and so on (the strictly rigid inheritance hierarchy OO imposes, you know..). The stone blocks are non-organic things, maybe they are rigid bodies or whatever, it doesn't matter.

If you are an artist and you have to find a stone block that makes a good "template" (?) for a statue of a human with given width, height an thickness, then you have to write a bunch of special case OO code to retrieve these attributes from the human model and from the stone block model. Or alternatively, your whole world model was build to support geometric queries - then it would be easy! But that leads to the conclusion that OOP sucks at representing data in a way that allows us to use it in different use cases. OOP just allows us to represent data for exactly those use cases that we have designed beforehand. Not much more. Any use besides those predeterminated cases can only be done with much fiddling. The relational model at least tries to represent data in a re-useable way. (re-useable: OOP once even occupied that word)

Why all that hate?

I work on a project that uses an ORM - and it just sucks. It started when modeling the database (because of ORM limitations), then came the time to learn the ins and outs of the ORM (and its bugs and further limitations), then came the fear of implicitly happening stuff (new thing(); thing->save() creates a new row, but where is "thing" rooted? why do people try to make objects as "independent" as possible but in the back create much more deeply rooted dependencies on freaking per-table-singletons, that communicate with connection-singletons.. oh my god .. I digress).

So many things that could have been done in a few lines of SQL and a sweet tiny query API were done in hundreds or maybe thousands of lines of "business logic" code (of course in the application layer, not in the database where the data is, and where aggregation functions like count() or sum() would be cheap). I think the people just feel better when they can work in OOP. But that is just stupid.

And the creators of ORM just want to keep the users away from the "dirty stuff". But exactly those people should not write ORM - the perfect example: I strongly believe that the ORM-creator type of people do not even know that a database table can contain compound primary keys! ;-)

So, why is OOP so occupying? It is just a half-baked abstraction, but people swear on it for everything, if you ask some, they may even tell you that OOP will create world peace.

Why is OOP so f***ing occupying/monopolizing?

Answer 1

OOP is just another tool in the toolbox, but keep in mind that OO has been the focus of mainstream programming languages for over 20 years now - starting with C++ and moving on to Java and C#. This probably has more to do with why the model is currently "so occupying" than anything else.

Answer 2

The point of OOP isn't necessarily to represent every single facet of every single object in the world. The point is to represent the stuff you care about. For instance, assume there's a house. Someone doing real estate stuff would care about the location, selling price, etc. A builder might care about the blueprint ID or something, i dunno. The point is, you model the important stuff and ignore the rest. Add to it later if you find you need more info.

Yes, this makes a "House" class tailored to the app being built, and possibly unsuitable for others. OOP's overall goal isn't to reuse classes, though sometimes that happens. The point is to bundle data with the actions that can affect that data, and to thus reduce a problem conceptually from hundreds of variables and functions to a few objects with known and tested interfaces and related behaviors.

Answer 3

Because at the end of the day it's a good approximation of the way we ourselves model things. The counter that is often raised to this is that computers have no concept of objects, it's all 1s and 0s, but that analysis is as empty as saying all human thought is nothing more than neurons and electrical impulses (which it probably is, but it's just not a useful way of looking at things).

So you don't like inheritance? Nor do I. Inheritance of behaviour is the poor man's code reuse. Inheritance of interface, on the other hand, is great as it gives us polymorphism.

You don't like ORMs? No one is forcing you to use them. There is a conflict between OOP and RDMS that I don't think is easily fixed and most ORMs attempts to resolve this are quite naive. The limitations of ORM are not a flaw in OOP.

Answer 4

It seems to me that if your business logic implementation is driving the design of your database, then somebody put the cart before the horse. I thought the idea was to develop a rational (no, I didn't say relational) data model and then implement whatever logic queries and updates the data.

My experience has been that although relational databases are great for storing and querying data from the user's perspective, trying to extend the relational model into a structured programming or OOP paradigm is difficult in the extreme. There's always a translation layer. Today everybody thinks that ORM is the solution. And although technically any translation layer that sits between a relational data store and an object oriented data access layer is ORM, when I see people talking about ORM these days they seem to be talking about some automated way of generating that ORM layer.

I'm not convinced that a generalized ORM solution exists. Every one I've seen is fraught with peril. It's a pain in the neck, but the only reliable ORM layers I've ever seen were hand coded. Granted, I haven't worked much with database stuff in the last five years or so, so things may have changed.

I'll agree with you that OOP is largely just a lot of syntactic sugar around a solid structured design. However, it's good syntactic sugar. It formalizes a lot of things that were considered "best practices" in structured programming, and adds some things (inheritance, interfaces, polymorphism, among others) that were very difficult or impossible to express in purely structured languages. We certainly could have added some or all of those features to structured languages without going all the way to OOP, but why? OOP was the obvious next step in the evolution of procedural programming languages.

Answer 5

The Human and StoneBlock should both inherit from MaterialObject, which has height width and depth attributes and even implements a biggerThan() method, when given another MaterialObject.

Answer 6

OO is "occupying" because it has shown to be an excellent choice for many programming problems. Similarly, the relational model has shown to be an excellent choice for many data storage and retrieval problems. When I say "many" I mean "so many that all other pale in comparison". In fact, both coupled together are an excellent combo, but there is complexity in mapping where these two paradigms meet, thus ORM.

I almost thought your question was insincere but then decided it was lack of experience (not intended as an insult, just guessing from the questions/assertions). You will find that there are problems so complex that OO is the only feasible way to model them. Not everything is a database-backed web site or reporting tool. Many systems are mostly "business logic" where the best solution is an OO solution (example from my experience: controlling and monitoring robotic aircraft and their various payloads). That being said, many of the popular database-backed web frameworks are OO+RDBMS (Rails, Grails, Java+Spring+Hibernate, etc.) because the combination is so powerful.

While there are certainly fads and sticky but outmoded paradigms, I suggest that when there are many choices (OO, functional programming, RDBMS-centric, etc.) people almost always choose what is the most productive. For at least 10 years, that has been OO for a large portion of software problems.