Is OOP hard because it is not natural?

Question

One can often hear that OOP naturally corresponds to the way people think about the world. But I would strongly disagree with this statement: We (or at least I) conceptualize the world in terms of relationships between things we encounter, but the focus of OOP is designing individual classes and their hierarchies.

Note that, in everyday life, relationships and actions exist mostly between objects that would have been instances of unrelated classes in OOP. Examples of such relationships are: "my screen is on top of the table"; "I (a human being) am sitting on a chair"; "a car is on the road"; "I am typing on the keyboard"; "the coffee machine boils water", "the text is shown in the terminal window."

We think in terms of bivalent (sometimes trivalent, as, for example in, "I gave you flowers") verbs where the verb is the action (relation) that operates on two objects to produce some result/action. The focus is on action, and the two (or three) [grammatical] objects have equal importance.

Contrast that with OOP where you first have to find one object (noun) and tell it to perform some action on another object. The way of thinking is shifted from actions/verbs operating on nouns to nouns operating on nouns -- it is as if everything is being said in passive or reflexive voice, e.g., "the text is being shown by the terminal window". Or maybe "the text draws itself on the terminal window".

Not only is the focus shifted to nouns, but one of the nouns (let's call it grammatical subject) is given higher "importance" than the other (grammatical object). Thus one must decide whether one will say terminalWindow.show(someText) or someText.show(terminalWindow). But why burden people with such trivial decisions with no operational consequences when one really means show(terminalWindow, someText)? [Consequences are operationally insignificant -- in both cases the text is shown on the terminal window -- but can be very serious in the design of class hierarchies and a "wrong" choice can lead to convoluted and hard to maintain code.]

I would therefore argue that the mainstream way of doing OOP (class-based, single-dispatch) is hard because it IS UNNATURAL and does not correspond to how humans think about the world. Generic methods from CLOS are closer to my way of thinking, but, alas, this is not widespread approach.

Given these problems, how/why did it happen that the currently mainstream way of doing OOP became so popular? And what, if anything, can be done to dethrone it?

Answer 1

OOP is unnatural for some problems. So's procedural. So's functional. I think OOP has two problems that really make it seem hard.

1. Some people act like it's the One True Way to program and all other paradigms are wrong. IMHO everyone should use a multiparadigm language and chose the best paradigm for the subproblem they're currently working on. Some parts of your code will have an OO style. Some will be functional. Some will have a straight procedural style. With experience it becomes obvious what paradigm is best for what:

   a. OO is generally best for when you have behaviors that are strongly coupled to the state they operate on, and the exact nature of the state is an implementation detail, but the existence of it cannot easily be abstracted away. Example: Collections classes.

   b. Procedural is best for when you have a bunch of behaviors that are not strongly coupled to any particular data. For example, maybe they operate on primitive data types. It's easiest to think of the behavior and the data as separate entities here. Example: Numerics code.

   c. Functional is best when you have something that's fairly easy to write declaratively such that the existence of any state at all is an implementation detail that can be easily abstracted away. Example: Map/Reduce parallelism.

2. OOP generally shows its usefulness on large projects where having well-encapsulated pieces of code is really necessary. This doesn't happen too much in beginner projects.

Answer 2

IMHO it is a question of personal taste and ways of thinking. I don't have much problem with OO.

We (or at least I) conceptualize the world in terms of relationships between things we encounter, but the focus of OOP is designing individual classes and their hierarchies.

IMHO this is not quite so, although it may be a common perception. Alan Kay, the inventor of the term OO, always emphasized the messages sent between objects, rather than the objects themselves. And the messages, at least to me, denote relationships.

Note that, in everyday life, relationships and actions exist mostly between objects that would have been instances of unrelated classes in OOP.

If there is a relationship between objects, then they are related, per definition. In OO you could express it with an association / aggregation / usage dependency between two classes.

We think in terms of bivalent (sometimes trivalent, as, for example in, "I gave you flowers") verbs where the verb is the action (relation) that operates on two objects to produce some result/action. The focus is on action, and the two (or three) [grammatical] objects have equal importance.

But they still have their well-defined roles in the context: subject, object, action etc. "I gave you flowers" or "You gave me flowers" aren't the same (not to mention "Flower gave you to me" :-)

Contrast that with OOP where you first have to find one object (noun) and tell it to perform some action on another object. The way of thinking is shifted from actions/verbs operating on nouns to nouns operating on nouns -- it is as if everything is being said in passive or reflexive voice, e.g., "the text is being shown by the terminal window". Or maybe "the text draws itself on the terminal window".

I disagree with this. IMHO the English sentence "Bill, go to hell" reads more naturally in program code as bill.moveTo(hell) rather than move(bill, hell). And the former is in fact more analog to the original active voice.

Thus one must decide whether one will say terminalWindow.show(someText) or someText.show(terminalWindow)

Again, it is not the same to ask the terminal to show some text, or ask the text to show the terminal. IMHO it is pretty obvious which one is more natural.

Given these problems, how/why did it happen that the currently mainstream way of doing OOP became so popular?

Maybe because the majority of OO developers see OO differently than you?

Answer 3

Some programmers find OOD hard because those programmers like to think about how to solve the problem for the computer, not about how the problem should be solved.

... but the focus of OOP is designing individual classes and their hierarchies.

OOD is NOT about that. OOD is about figuring out how things behave and interact.

We think in terms of bivalent (sometimes trivalent, as, for example in, "I gave you flowers") verbs where the verb is the action (relation) that operates on two objects to produce some result/action. The focus is on action, and the two (or three) [grammatical] objects have equal importance.

The focus on OOD is always on action, where actions are the behaviours of objects. Objects are nothing without their behaviours. The only object constraint of OOD is that everything has to be done by something.

I don't see the doer as more important then the thing having something done to it.

But why burden people with such trivial decisions with no operational consequences when one really means show(terminalWindow, someText)?

To me that's the same thing with a different notation. You still have to decide who is the show-er and who is the show-ee. Once you know that, then there is no decision in OOD. Windows show text -> Window.Show(text).

A lot of stuff out there (especially in the legacy area) says it is OO when it is not. For example there is a huge amount of C++ code that does not implement a fig of OOD.

OOD is easy once you break out of the mindset that you are solving a problem for computers. You are solving problems for things that do stuff.

Answer 4

Maybe, I am not able to get the point, but:

Reading the first book on OOP (early 90s, Borland's thin manual to Pascal) I was simply amazed with its simplicity and potential. (Before, I had been using Cobol, Fortran, Assembly language and other prehistorical stuff.)

For me, It is pretty clear: a dog is an animal, an animal must eat, my dog is a dog, so it must eat ...

On the other side, programming itself is inherently unnatural (i. e. artificial). Human speech is artificial (do not blame me, we all have learned our languages from others, nobody knows the person who invented English), too. According to some scientists, human's mind is formed by the language he has learned first.

I admit, some constructs in modern OO-languages are a little bit awkward, but it is the evolution.

Answer 5

One thing that made it hard for me was thinking that OOP was about modelling the world. I thought that if I didn't get that right, something might come and bite me in the ass (a thing is either true or its not). I was very aware of the problems that pretending everything is an object or entity. This made me very tentative and under-confident about programming in OOP.

Then I read SICP and came to a new understanding that it really was about data types and controlling access to them. All the problems I had melted away because they were based on a false premise, that in OOP you are modelling the world.

I still marvel at the immense difficulty that this false premise gave me (and how I let myself be beholden to it).

Answer 6

Yes, OOP itself is very unnatural - the real world is not entirely made of hierarchical taxonomies. Some little parts of it are made of that stuff, and that parts are the only things that could be adequately expressed in terms of OO. All the rest can't be naturally fit into such a trivial and limited way of thinking. See the natural sciences, see how many different mathematical languages had been invented in order to express in the simplest or at least comprehendable way the complexity of the real world. And almost none of them can be easily translated into a language of objects and messages.

Answer 7

We (or at least I) conceptualize the world in terms of relationships between things we encounter, but the focus of OOP is designing individual classes and their hierarchies.

You're starting from (IMO) a false premise. The relationships between objects are arguably more important than the objects themselves. It's the relationships that give an object oriented program structure. Inheritance, the relationship between classes, is of course important because an object's class determines what that object can do. But it's the relationships between between individual objects that determine what an object actually does within the bounds defined by the class, and therefore how the program behaves.

The object-oriented paradigm can be difficult at first not because it's difficult to think up new categories of objects, but because it's difficult to envision a graph of objects and understand what the relationships between them should be, particularly when you don't have a way to describe those relationships. This is why design patterns are so useful. Design patterns are almost entirely about the relationships between objects. Patterns give us both the building blocks that we can use to design object relationships at a higher level and a language that we can use to describe those relationships.

The same is true in creative fields that work in the physical world. Anyone could throw together a bunch of rooms and call it a building. The rooms might even be fully furnished with all the latest accoutrements, but that doesn't make the building work. The job of an architect is to optimize the relationships between those rooms with respect to the requirements of the people using those rooms and the building's environment. Getting those relationships right is what makes a building work from both functional and aesthetic perspectives.

If you're having trouble getting used to OOP, I'd encourage you to think more about how your objects fit together and how their responsibilities are arranged. If you haven't already, read about design patterns -- you'll likely realize that you've already seen the patterns you read about, but giving them names will let you see not just trees, also but stands, copses, thickets, woods, groves, woodlots, and eventually forests.

Answer 8

This is only a part of what's wrong with OOP.

Essentially, functions become second-class citizens, and this is bad.

Modern languages (ruby/python) don't suffer this problem and provide functions as first class objects, as well as allowing you to make programs without building any class hierarchy.

Answer 9

OOP is not hard. What makes it difficult to use well is a shallow understanding of what it's good for, where programmers hear random maxims, and repeat them to themselves under their breath in order to receive the blessings of the divine Gang of Four, the blessed Martin Fowler, or whoever else they've been reading.

Answer 10

EDITED

First of all I would like to say that I never found OOP hard, or harder than other programming paradigms. Programming is inherently hard because it tries to solve problems from the real world and the real world is extremely complex. On the other hand, when I read this question I asked myself: Is OOP "more natural" than other paradigms? And therefore more effective?

I once found an article (I wish I could find it again so I could post it as a reference) about a comparative study between imperative programming (IP) and object-oriented programming (OOP). They had basically measured the productivity of professional programmers using IP and OOP in different projects, and the result was that they had not seen big differences. So, the claim was that there was no big difference in productivity between the two groups, and that what really counts is experience.

On the other hand, proponents of object-orientation claim that, while during the early development of a system OOP may even take more time than imperative, in the long run the code is easier to maintain and extend due to the tight integration between data and operations.

I have worked mainly with OOP languages (C++, Java) but I often have the feeling that I could be as productive using Pascal or Ada even though I never tried them out for large projects.

Contrast that with OOP where you first have to find one object (noun) and tell it to perform some action on another object.

[cut]

I would therefore argue that the mainstream way of doing OOP (class-based, single-dispatch) is hard because it IS UNNATURAL and does not correspond to how humans think about the world. Generic methods from CLOS are closer to my way of thinking, but, alas, this is not widespread approach.

When I read this last paragraph more carefully I finally understood the main point of your question and I had to rewrite my answer from scratch. :-)

I know of other OO proposals where multiple objects receive a message instead of only one, i.e. several objects play a symmetric role when receiving a message. YES, this seems a more general and maybe more natural (less restrictive) OOP approach to me.

On the other hand, "multiple dispatch" can be easily simulated using "single dispatch" and "single dispatch" is easier to implement. Maybe this is one reason why "multiple dispatch" hasn't become mainstream.

Answer 11

Stop looking for an exclusively OOP paradigm and try on some JavaScript.

I currently have something of a scheme worked out where my UI objects are operating under an event-driven interface. That is to say, I'll have what looks like a typical public method that when fired results in an internally defined action. But when it's fired, what really happens is that I trigger an event on the object itself and a pre-defined handler inside that object responds. This event and the event object you can attach properties to that gets passed to any other listener can be heard by anything that cares to listen. You can listen directly to the object, or you can listen generally for that event type (events are also triggered on a generic object all objects built by the factory can listen to). So now for instance, I've got a combo box where you select a new item from the dropdown list. The comboBox knows what to do to set its own display value and update the server if it needs to, but I can also have as many other combo boxes as I want listening in to swap out their select lists which are tied to the current value of the first combo box.

If you want, (and I was surprised to discover that I don't usually want - it's a legibility issue when you can't see where the event comes from) you can have complete object decoupling and establish context via a passed event object. Regardless, you're still dodging single-dispatch by being able to register multiple responders.

But I'm not doing this with OOP alone and JS is not even 'properly' OOP by some definitions, which I find hilarious. Proper, for the higher levels of app development in my opinion, is having the power to bend the paradigm to whatever works for your situation and we can emulate classes just fine if we care to. But in this case, I'm mixing aspects of functional (passing handlers around) with OOP.

More importantly, what I have feels pretty powerful. I'm not thinking in terms of one object acting on another. I'm basically deciding what the objects care about, giving them the tools they need to sort things out and just dropping them into a mixer and letting them react to each other.

So I guess what I'm saying is this: it's not a switch statement kind of a problem. It's mix and match. The problem is languages and fads that want you to believe it's one thing uber alles. How can a junior java dev, for instance, truly appreciate OOP when they think they're always doing it properly by default?

Answer 12

The way it was explained to me was with a toaster and a car. Both have springs, so you'd have a "spring" object and they'd be different sizes, strengths and whatever, but they'd both be "springs" and then extending that metaphor onto the car, were you have lots of wheels (Wheels, obviously, plus the steering wheel, ect) and that made a lot of sense.

You then can think of the program as a list of objects, and it's much simpler to visualize then "It's a list of things that do stuff, so it's not like that list of instructions you saw before"

I think the real problem with OOP is how it's explained to people. Often (in my uni classes) I see it being explained by saying "it's about lots of classes that do little things, and you can create objects out of that" and it all confuses a lot of people, because it's using what are essentially abstract terms to explain these concepts, rather then concrete ideas that people have grasped when they were 5 years old playing with lego.

Answer 13

It's the natural way to think of the world through categorisation. That's more or less what OO is about. OOP is hard because programming is hard.

Answer 14

I think some of the difficulty comes in when people try to use OOP to represent reality. Everybody knows that a car has four wheels and an engine. Everybody knows that cars can Start(), Move() and SoundHorn().

A light clicked on in my head when I realised I ought to stop trying to do this all the time. An object is not the thing that it shares a name with. An object is (i.e. should be) a sufficiently-detailed partition of data relevant to the scope of the problem. It ought to have exactly what the solution to the problem needs it to have, no more and no less. If making an object responsible for some behaviour results in more lines of code than the same behaviour being the job of some nebulous third party (some might call it a 'poltergeist') then the poltergeist earns its chips.

Answer 15

In order to manage complexity, we need to group functionality into modules, and this is a difficult problem in general. It's like the old saying about capitalism, OOP is the worst system for organizing software out there, except for everything else we've tried.

The reason we group interactions inside the nouns, even though there is frequently an ambiguity about which of the two nouns to group it with, is that the quantity of nouns happens to work out to manageable sized classes, whereas grouping by verbs tends to either produce very small groups like one-offs, or very large groups for a function like show. Reuse concepts like inheritance also happen to work out much easier when grouping by nouns.

Also, the question of deciding whether to put show with the window or the text is almost always much more clear in practice than in theory. For example, nearly all GUI toolkits group add with the container, but show with the widget. If you try to write code the other way, the reason becomes apparent fairly quickly, even though thinking about it abstractly the two methods seem interchangeable.

Answer 16

No. There are several ways to solve a proble using Programming: functional, Procedural, logical, O.O.P., other.

In the real world, sometimes, people use the functional paradigm, and sometimes, we use the procedural paradigm, and so on. And sometimes we mixed up. And eventually we represent them as a particular style or paradigm of programming.

There is also the "everything is a list or a item" paradigm, used in LISP. I like to mention as a different thing from functional programming. PHP uses that in associative arrays.

O.O.P. and "Everything is a list or item" paradigms are consider 2 of the MORE NATURAL programming styles, as I remember in some Artificial Intelligence classes.

Sounds to me weird, "O.O.P. is not natural", maybe the way you learn, or the way you have been taught about O.O.P. is wrong, but not O.O.P. itself.

Answer 17

Given these problems, how/why did it happen that the currently mainstream way of doing OOP became so popular? And what, if anything, can be done to dethrone it?

OOP became popular because it offers tools to organize your program at a higher level of abstraction than the popular procedural languages that preceded it. It was also relatively easy to make a language that had procedural structure inside of methods, and object-oriented structure surrounding them. This let programmers who already knew how to program procedurally pick up OO principles one at a time. This also led to lots of OO-in-name-only programs that were procedural programs wrapped inside a class or two.

To dethrone OO, build a language that makes it easy to transition incrementally from what most programmers know today (mostly procedural, with a little OO,) to your preferred paradigm. Make sure it provides convenient APIs to do common tasks, and promote it well. People will soon be making X-in-name-only programs in your language. Then you can expect it to take years and years for people to get good at actually doing X.

Answer 18

I think the OOP and OOP languages have problems too.

If understand it correctly, OOP is about black boxes (objects) which has push buttons on them that can be pushed (methods). Classes are just there to help organize these black boxes.

One problem is when the programmer puts the push buttons on the wrong object. The terminal cannot show text on itself, the text cannot show itself on the terminal. The window manager component of the operating system that can do that. Terminal window and text is just a passive entity. But if we think this way we realize the most entities are passive things and we would have only a very few objects that actually do anything (or simply one: the computer). Indeed when you use C you organize it into modules, these modules represent that few objects.

Another point is that the computer just executes instructions sequentially. Let's assume you have a VCR and a Television object, how would you play video? You probably write something like this:

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

This would be this simple, but you would need at least 3 processors (or processes) for that: one plays the role of you, the second is the VCR, the third is the TV. But normally you have only one core (at least not enough for all your objects). In college, lot of my classmates did not understand why the GUI freezes when a push button does an expensive operation.

So I think an object oriented design may describe the world quite well, but it's not the best abstraction for the computer.

Answer 19

Take a look at DCI (data, context and interaction) invented by the inventor of the MVC pattern.

The goal of DCI is (quoted from Wikipedia):

• Give system behavior first-class status, above objects (nouns).
• To cleanly separate code for rapidly changing system behavior (what the system does) from code for slowly changing domain knowledge (what the system is), instead of combining both in one class interface.
• To support an object style of thinking that is close to peoples' mental models, rather than the class style of thinking.

Here's a good article by the authors and here's is a small example implementation (.NET) if you want to see some code. It's much simpler than it might sound, and feels very natural.

Answer 20

One can often hear that OOP naturally corresponds to the way people think about the world. But I would strongly disagree with this statement (...)

As it is evangelized in books and elsewhere for decades, I disagree with it too. Nevertheless, I think Nygaard and Dahl were the ones that put it that way, and I think they were focusing on how easier it was to think about designing simulations compared with the alternatives of the time.

(...) but the focus of OOP is designing individual classes and their hierarchies.

This assertion enters sensible territory given how popular misconceptions of OOP are, and how sensitive OO is to definition. I have more than ten years in the field, doing both industry work and academic research on prog. languages, and I can tell you I spent many years unlearning "mainstream OO" because I started noticing how different (and inferior) it is from what the earlier creators were aiming at. For a modern, up to date treatment of the subject I would refer to W. Cook's recent effort:

"A Proposal for Simplified, Modern Definitions of "Object" and "Object Oriented" http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

Given these problems, how/why did it happen that the currently mainstream way of doing OOP became so popular?

Maybe the same reason QWERTY keyboards came to be popular or the same reason DOS operating system became popular. Things just get a ride on popular vehicles, despite their properties, and become popular themselves. And sometimes, similar but worse versions of something are taken to be the actual thing.

And what, if anything, can be done to dethrone it?

Write a program using a superior approach. Write the same program using an OO approach. Show the former has better properties than the latter in every aspect that is significant (both properties of the system itself and engineering properties). Show that the program chosen is relevant and the proposed approach sustains the high quality of properties if applied to other kinds of programs. Be rigorous in your analysis and use precise and accepted definitions when necessary.

Finally, share your findings with us.

Answer 21

Take Java: objects are a kind of abstraction bottleneck, most "things" are either strictly sub-components of objects or use objects as their sub-components. Objects must be multi-purpose enough to an entire abstraction layer between these two types of things -- muti-purpose means there is no one metaphor that they embody. In particular Java makes objects (& classes) the sole layer through which you call/dispatch code. This amount of things objects embody makes them, frankly, far too complex. Any useful description of them must be restricted to some specialized or restricted form.

The inheritance & interface hierarchies are "things" that use objects as sub-components. This is one specialized way of describing objects, not a way to derive general understanding of objects.

"Objects" can be said to have or to be many things because they are a multi-purpose abstraction that is more-or-less universal in an "OO Langauge". If they are used to contain local mutable state or to access some external world state then they look very much like a "noun".

By contrast, an object that represents a process, e.g. "encrypt" or "compress" or "sort", looks like a "verb".

Some objects are used for their role as a namespace, e.g. a place to put "static" function in Java.

I am inclined to agree with the argument that Java is too heavy on object method calls, with dispatch on the object. This is probably because I prefer Haskell's type classes for controlling dispatch. This is a dispatch limitation and is a feature of Java but not most languages, or even most OO langauges.

Answer 22

I have witnessed and participated in many online debates about OOP. The proponents of OOP usually do not know how to write proper procedural code. It is possible to write procedural code that is highly modular. It is possible to separate code and data and ensure that functions can only write to their own data store. It is possible to implement the concept of inheritance using procedural code. More importantly, procedural code is slimmer, faster and easier to debug.

If you build single-file modules with strict naming conventions, procedural code is easier to write and maintain than OO and it will do the same or more and faster. And don't forget that when your application runs, it is always procedural no matter how many classes feature in your script.

Then you have the issue of languages like PHP, which are not truly Object Oriented and rely on hacks to fake stuff like multiple inheritance. The big shots who influence the direction of the language have turned PHP into a patchwork of inconsistent rules that have become too big for what it initially intended. When I see developers write huge templating classes for what was intended as a procedural templating language, I can't help but smile.

If you compare properly-written OO code with poorly-written procedural code, then you will always come to the wrong conclusion. Very few projects warrant an Object Oriented design. If you are IBM and manage a huge project that needs to be maintained for years by multiple developers, go for Object Oriented. If you are writing a small blog or shopping website for a client, think twice.

To answer the original question, OOP is hard because it does not solve real-life programming dilemmas without resorting to solutions that are 100 times more complicated than they should be. One of the most powerful solutions to many programming problems is the judicious use of global data. Yet the new-wave university graduates will tell you that it is a big no-no. Globally-available data is dangerous only if you are a clumsy programming bunny. If you have a strict set of rules in place and proper naming conventions, you can get away with having all of your data global.

It should be a mandatory requirement for any Object Oriented programmer to know how to write a chess-playing application in assembler for a maximum available memory of 16K. They would then learn how to trim the fat, cut the laziness and generate ingenious solutions.