I quote Edsger Dijkstra (1930-2002), a great Dutch programmer and writer:

“Object-oriented programming is an exceptionally bad idea which could only have originated in California.”

The 3 promises

Object Oriented Programming (OOP) is promising us:

hide implementation details optimal reuse of code hiding state, combining code and data

In my experience Object Oriented Programming Languages are no better at #1 and #2 than procedural languages. And #3 may seem logical as we have data and code. This code manipulates the data that should be in a well structured and preferably standardized format. But combining code and data is in my opinion not always a good idea (more on that later).

Accidental obfuscation

Unfortunately these are the characteristics of many OOP code bases I have seen:

hard to learn many lines of code low performance

In most cases we do not need IoC, LSP or even SOLID. We don’t need castles built of (Java) classes. We don’t want to read 10 different classes and interfaces to understand often trivial implementations. Programming is hard enough without people accidentally obfuscating what is going on.

Nobody complains about OOP like Zed Shaw in the above video from exactly 17:24. Click the image to play the video from that point (takes about five minutes).

Use. Less. Classes.

While Object Oriented Programming may lead to the characteristics described above, software (developers) should focus on achieving the opposites:

easy to learn few lines of code high performance

The world seems to realize this nowadays. We see that new non-OOP languages like Rust and Go are emerging, while established OOP languages like C++ and Ruby are struggling. Also, make sure you watch Jack Diederich “Stop Writing Classes” talk from PyCon 2012:





Definitely a video worth watching. Click on the image above to start the video.

Where we really take it too far

You may argue Object Oriented has its place in some software niches. But in the database world (administrative applications) it has not. A database record is not an object. Data should not (and can not) be abstracted. Object Relational Mapping and object oriented data API’s are taking OOP way too far.

You cannot make abstractions to anticipate on future (data model) changes. How are you going to abstract missing data? Or added data? Versioning an API is fine, as long as the API is not exposing data. Behavior can be versioned and the versions can co-exist. But versioned contracts on data and it’s structure do not make sense to me.

Conclusion

Mixing code and data is not always a good idea. OOP is based on this idea. Therefor do not apply OOP without some critical thinking first.

Further reading

Much more has been said about OOP and it being a bad idea. These links are in no particular order:

If you feel like learning about this somewhat controversial point-of-view, then I recommend you to read the list above.