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

fabrizio duroni

Ever wondered about the differences between data structures and objects? Let's analyze them with the help of the Law of Demeter.

At 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.

Read next

Evolution of a high-performance system: from synchronous to seamless scalability

Evolution of a high-performance system: from synchronous to seamless scalability

giuseppe pinto

This article discusses the transformation of a synchronous process in the context of's customer journey for travel planning. The existing system was complex and resource-intensive due to its all-in-one nature, causing scaling and deployment challenges. The article presents the evolved system that separates responsibilities into microservices using message-driven communication. [...]

Lambda Integration with MSK and KrakenD

Lambda Integration with MSK and KrakenD

otto abreu

API Gateways can be a simple way to expose asynchronous communication without revealing too many details about it but, is not always an easy task to implement. In this post, I explore a way to expose Kafka topics in a well-known API Gateway (KrakenD) while circumventing multiple limitations. [...]