Goodbye OO

What do you guys/girls think?


I think it’s quite a bit exaggerated. There are pros and cons with all solutions, and personally I like working with OO a lot.

Your code can break from a change in the code you reference, OO or not. In the example of a method being re-used I’d say this is what should have been done from the start, rather than repeating the same code. Then the derived class should only have to override one method, not two. In any case the documentation should clearly tell what the code does; does it repeatedly call the other method or does it stand on its own? If required for optimization, the code could be repeated to avoid an extra method call, but as already stated, the documentation should cover this.

Also, having multiple values holding what is essentially the same information is in my experience an invitation to errors. Storing the array length separate from the array, which has an actual length, introduces the risk of getting these values out of sync. Of course there are reasons to cache data for optimization, but very often I’d say it’s better to calculate a derived value on the fly when needed.

I don’t get the objection to categorical hierarchies. I’d say the world is full of them. Every human is a primate, every private is a mammal and so on. Every edge is a drawingelement and every drawingelement is an entity. Every class represent a subset of its parent class. Easy peasy.

Containment hierarchies exists too, as namespaces, but that is a separate hierarchy. Behaviors are inherited from the categorical super-set, not the owner. A sock has things in common with other cloths, not with the sock drawer, the cabinet, or the bedroom.

The objection to encapsulation doesn’t make much sense to me either. If you pass something as an argument to a constructor, you want/need it to be accessible from elsewhere, otherwise you couldn’t have passed it to the constructor. Encapsulation is great for things you want only to be accessible from within a class, and allows you to expose a simplified interface that can be easily used without having to know how things work under the hood. Forcing the rest of the program to interact only with public methods encourages de-coupled classes, where internal changes can be made much more safely.

1 Like

I’m surprised that he wrote only two years ago as if he had just come to understand these issues (and as if he thought of them on his own, without crediting those who came before him). They were already known and hotly discussed by computer language theorists in the late 1980’s and early 1990’s. Many of them arose when people applied static, strongly-typed programming mechanisms to OO, leading to emphasis on categorizing what a thing is rather than what it does. Note that Ruby cares whether an object can respond to a named method, not where or how it got that method. You can scan the CS literature from that era for a trove of thoughts about these matters.

I was amused that he cited the old joke (which I heard as "I wanted a banana and they made me take a monkey, a cage, a zookeeper, and a zoo with it) in reference to OO. I originally heard it in regard to strongly-typed programming libraries, which require that you utilize their entire suite of special types because that’s all that will work with their interfaces.


Not any post that is pusblished with the professional press design of Medium (same for TED talks) is a significant message to the world.

It sounds like the author has a very personal understanding of things and then criticizes them for that.

I haven’t seen yet a paradigm or ideology that is the only truth in its field. Paradigms are idealized and dogmatized concepts. As everywhere, one has to know one’s tools and when to apply which.

Categorical hierarchies exist, but there can be many overlapping possibilities (number of legs, humans and birds are bipeds), so it depends on a precise definition of category criteria and on a wise decision on which precedence to use (as top-level etc.). This is totally independent from object orientation.

He blames encapsulation for a specific case of external access to internals through references. There are three solutions, 1. just don’t modify the object from outside anymore (and hope nobody else does), 2. do an expensive deep copy of the external object before it is owned by the internal encapsulated implementation, 3. realize that what you need is ownership/access control and use a modern language that supports that concept, too.
Programming language designers orient themselves on one or several paradigms and often think up totally new concepts. This means progress.


I just stumbled upon this blog, while attempting to get rid of some subscriptions as part of my new year resolution: an empty mailbox.

At first, I decided to put all my mail in folders and subfolders and was contemplating on how to organise:
By nature (work,personal)
By sender
By subject
Etc etc.

This would be an adequate system when the mails you receive would actually be physical mails, like the books in a library, or the nails and hinges in the hardwarestore.

But (e)mail is not physical and though it looks very organised and complete, you can always have ‘stray edges’
With all the search functions of today (Google’s search engine and algoritmes are implemented in Google mail as well) one would just have to type the right search tags for a certain mail to pop up.

Like this discourse forum, google mail uses labels for organisation, not actual folders itself, and I have often wanted to see if you could implement such organisation in SketchUp.

How much hiarchy is needed? If you import an ifc model, you’ll notice very strict and deeply nested components and if it wasn’t for the outliner, it would take a zillion clicks to enter a component for editing.

So would a flat organisation be beneficial (no nesting levels at all, just groups or components)?
The search filter in the outliner would act as the google engine, provided that you would name your components in a logical manner (@maxB ?)

Anyways, the answers here would direct me to the good old ‘best of both worlds’ method, I guess!

In a model, I would say a component hierarchy helps not only organizing the model (what is what) but also manipulating related things as one thing. In a flat hierarchy, I would have to select the house and the chair and the second chair etc. to move them together. That’s why I create a house component that I can select with one click and it keeps the chairs and tables together (bundling).

We could imitate this in a flat hierarchy by giving the house a “house” tag and tagging the chair with “chair” and “house”. Then instead of clicking every item that belongs to the house I would batch-select all items tagged as “house”. The difference is that the chair nested in the house component does not know that it belongs to the house (information hiding), whereas the tagged one does.

I agree, too deeply nested hierarchies have disadvantages. For my use case the internals of the chair component could be just flat (whereas the chair designer maybe has reasons to organize them further).

In a purely flat hierchy, should there be groups/components at all? If you have groups without further nesting, someone has to decide what the group comprises (chair leg), and for someone else it is not the right granularity (chair). Hierarchies allow to choose the right granularity.


I think this article is a pretty clear case of “computer science theory” colliding with “real world usage”. Certainly there could be some perfect design philosophy and language that would provide all of the power and features we need without any downsides - but I won’t hold my breath. Like any tool, OO C++ certainly has upsides and downsides, but we can see the overall balance by looking at how much people have gotten done using that tool & approach.

The author also sets up a number of straw men regarding concepts like reuse. For example, he wants to reuse a class in another project and then gets dismayed that he has to bring in the entire hierarchy. That’s an attempt to implement reuse at the wrong level. If you want reuse, create a library with a good interface and then use that library. Copy/pasting classes from one project to another is the exact opposite of re-use.

With all of that said, certainly the precepts of functional programming are very attractive. The idea of avoiding side effects in particular helps people avoid some of the biggest pitfalls of other paradigms.


How much hierarchy I need depends on the project at hand. I try to keep the amount as low as possible (more levels=more objects=more chance of more slow SU). Normally I have:

  • 1 container (component) for the house / office
  • 1 container for the sub-levels (basement / foundations)
  • 1 container for the terrain, trees etc.

In those containers I put all the named groups and components for the outer walls, inner walls, windows, furniture etc. A single chair would be moved into the furniture group. I try to keep the hierarchy as small as possible so the Outliner needs no/small amount of scrolling. I rarely/never use the search function because of this.

Its a flexible system. Some projects need a different hierarchy - each level could be a container. Keeping it flexible is key to me.

Edit: and as to the original Goodbye OO question: there are many routes that lead to Rome. I don’t think there is only one good solution and the rest is ■■■■. Just pick the one that fits your workflow / you already are comfortable with. Keep an open mind though and look around to see if improvements can be made / better options come along.