Why we fail OO

The Problem

I have read a lot of posts and articles on why Object Oriented Programming has failed and why should not we use it. Yet OO/OOP has not failed we have failed it.

Some have failed OO because they are still learning and others are simply lazy. While we can all forgive the former the latter is probably going to upset some people. My intention is not to upset but to get people to think differently and realise the work required to make a good OO implementation is not quick, nor easy but that the result will be easier to understand, maintain and reuse and this is where OO starts to pay dividends. You have to put the work in up front or you will have failed OO.

In a nutshell we need to model the real world in OO and that is where we got into trouble. Most times developers use provided objects to represent Business concepts and that is wrong. I have never heard a Business person or Customer say they need a Map of Students or a String representing a Customers name. They don’t speak in terms of implementation classes yet we use almost all of the classes provided in a runtime as Business classes. This is quick and easy but it is wrong and it is where the trouble starts.

Not one class in the Java Runtime is a Business Object they are utility classes for building the Business objects. I can probably make a safe assumption this is the case for most runtimes.

How many times have you seen a Customer class with a field / property called name that is a String?

The Fix

When a class represents a Business concept (these are the things your Customer or Business person talks about) this class should not be a provided runtime class. It should instead be a new class where each of its fields / properties are themselves Business classes.

public class Students {
    private final Map<StudentIdentifier, Student> students;
public class Student {
    private final StudentName name;
public class StudentIdentifer {
    private final UUID id;
public class StudentName {
   private final String name;

When you take this approach you start to do OO and model the real world (your Business Domain) in an Object Oriented manner. Yes it takes a little longer. For example in the above it would be quicker and easier to directly use a String as the StudentName and a UUID as a StudentIdentifier but you will not have modeled your Business and you will have removed the ability to add methods to the right class when needed. In some runtimes like Java’s the String class is final and you cannot even add a method to it, which should tell you this is the wrong approach. Besides, even if you could add a method to String you now have a pile of other methods in String that don’t necessarily relate to the concept being modeled; a Students Name. This is where reuse starts to be whittled away as you can’t stop a developer from using these other methods incorrectly (coupling you to String).


Yes this post is opinionated but I have in my experience found that this approach is only a little more time consuming up front yet it repays this ten fold as the implementation continues. Don’t be the one that fails OO or says that OO has failed until you take this approach since (in my opinion) not taking it is failing OO.

In addition to the approach the implementation can also be improved by adopting some of the other approaches I have mentioned in other posts like Object Calisthenics.

Eloquently East

Peter DiSalvo has written a very eloquent post on Object Oriented Design and has mentioned East Oriented. It is well worth a read if you are interested in OO or East.

You can read it HERE. The opening paragraph is a must read.


Philosophy I found this on the interwebs and wanted to catch it here for future reference.

Object Calisthenics

In addition to East Oriented Design I also promote following the Object Calisthenics approach.

William Durand’s write up: Object Calisthenics
Java World’s write up: Object Calisthenics

Object Calisthencis is about changing the way you code as is East Oriented Design.


9 steps to better software design today, by Jeff Bay:

Only One Level Of Indentation Per Method
Don’t Use The ELSE Keyword
Wrap All Primitives And Strings
First Class Collections
One Dot Per Line
Don’t Abbreviate
Keep All Entities Small
No Classes With More Than Two Instance Variables
No Getters/Setters/Properties

Old Blog

This is my new blog hosted by github pages and I’m using Jekyll etc.

All the old posts will be re-done and returned here as soon as I have time to move them.

If there is a particular post you are after then let me know and I’ll try to move that over first.