Clean Code: data structures vs objects and the law of Demeter

At lastminute.com group we love Clean Code, the software development approach created by Robert Cecil Martin “Uncle Bob”. In this post I will talk about Data structures and objects from a Clean Code point of view. Let’s start with a quote from the “Uncle Bob” Clean code book:

Objects hide their data behind abstractions and expose functions that operate on that data. Data structures expose their data and have no meaningful functions.

It’s easy to see that data structures and objects are opposites. A lot of programmers are convinced of the fact that in software development everything should be an object. If you think about the nature of objects you will see that there are times where you just want simple plain data structures that you can manipulate in a procedural way. This is a consequence of the fact that adding new functions to an object may require much more work, because maybe you need to modify all the objects of the same type to add a new function. This give us the following definitions, again a quote from Clean Code book:

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. Object oriented code, on the other hand, makes it easy to add new classes without chaging existing functions.

Procedural code makes it hard to add new data structures because all the functions must change. Object oriented code makes it hard to add new functions because all the classes must change.

This set of rules must guide you when it’s time to choose between objects vs procedural implementation:

• do you expect to add more and more functions to your code, and keep unmodified the data structures you use? Ok, let’s go with procedural code.
• do you expect to add new types without adding new functions to your code? Well, use objects.

Related to the object oriented programming, Uncle Bob talks about the law of Demeter that says a module should not know about innards of the objects it manipulates. The focus of this law is to improve the decoupling of objects. More precisely its definition is:

A method f of a class C should only call the methods of these:

• C
• an object created by f
• an object passed as argument to f
• an object held in a instance variable of C

This bring us to talk about what is called train wreck: concatenation of function/properties calls. The difference between objects and data structures gives us a clear understand of when a train wreck is really dangerous:

• if in a method you’re working with data structures, law of Demeter is not applied to them because is natural for a data structure to expose their internal structure
• if in a method you’re working with objects, then you should consider concatenation of method calls as violation of the law of Demeter

The next time you will write a piece of code try to consider these concepts and how they can improve your code.