A revised approach to Object Orientated Programming

This article, based on the views of Kevin Henney, aims to give developers a new way to look at OO programming.

Human nature defines the way we think and how we assume that someone else knows exactly what we are thinking about without the need to explain it.  In Object oriented program design developers may also assume this, which is where messy code will arise.  Each time you are designing a piece of code, if it is necessary to provide instructions on how to use the code then more than likely it is a failed design.

If you were to design a door you wouldn’t usually expect users to push a handle, but it’s even worse if it has an instruction to push. This would be a particularly counter intuitive design and, similarly to a door design, good principles should apply to designing code.  Many developers will also associate a real life object to an object in code which can be a naïve model and not always true.

The following outlines some common issues regarding object oriented program design and how to avoid repeating widespread mistakes.

1. Singleton.  The Singleton is a very common design technique however any good design pattern should have a set of advantages and equally some set of consequences.  The singleton doesn’t really have any set of consequences which means there could be an issue with it  Often this pattern can be implemented in different ways.  Constraints should be placed on the application and not really on the type.  You should be able to simply use parameters and pass as arguments.  Object oriented programming should be about code reuse, so a factory design that only produces one object seems a bit out of scope.
   
2. Coupling.  A frequent  issue regarding coupling concerns multiple dependencies within the object hierarchies.  The traditional model is a top down Infrastructure -> Services -> Domain approach which leads to a rippling of errors down the hierarchy if you want to change the top layer.  An alternate option is a domain oriented approach, where the relationships are horizontal in nature and interfaces promote the idea of polymorphism and assign relationships by delegation.
   
3. Interfaces.  These are often implemented as an abstraction of the concrete base class.  Instead, think about the actual role that it plays.  If you think about what the interface supplies to the client classes rather just satisfying the concrete class you will unlock a different way of designing good interfaces.
   
4. Getters/Setters.  Getters and Setters seem to have become a reflex action in today’s shortcut key oriented programming.  These cause 2-3x more coding time and sometimes they are just not needed and often produce unreadable code. Use them only if there is a need and to name things appropriately, for example the bonding between couples is known as ‘marriage’ not ‘get spouse’, for a ‘list==0’ operation you should create a isEmpty function.
   
5. Constructors.  A misunderstanding of constructors is that it only initialises.  It is capable of so much more;  it is a transaction, if the creation passes then a new instance is created, a control flow is created and a new object is produced, otherwise it should fail in a coherent way.  Some developers have the tendency to create objects inside the constructor, this should be avoided because you would need to instantiate outside of the constructor which is an unnatural way to code.

Finally, to end this article, let’s think about unit testing, if from your code you can generate good unit tests then the code design is probably of a high standard.  You should name tests appropriately and meaningfully  so that you can identify each test's purpose hence you can see the flow of the object oriented design and what it’s doing as well.  Try to avoid naming unit tests; test1, test2 and test3 etc as these have no meaning.

Following some of the above guidelines will hopefully open a developer up to a better way of object oriented design.