What is this lie? It’s not subtle – and in fact like any great deception – it has been doubled-down on over and over again. So much so, that it’s actually carried around as if it were the DEFINITION of truth – the one true way to design software. And like many of the most successful lies throughout history – it seems viable, even helpful in the short term but carries with it long-term, bad consequences.
The lie goes something like this “The purpose of an object is to encapsulate data behind behavior”. The idea is that we expose the things we want to do, and then implicitly have some backing information with which we accomplish those things.
As with any good lie – it starts with a kernel of truth – viz. yes, exposing only one thing is important, so you shouldn’t expose data if you are going to expose behavior. The lie begins with the idea, that the object, a single object, embodies both.
At a bare minimum, this will always represent a violation of SRP. No matter how closely related, specific behavior and any data that are related to that behavior represent two reasons to change, and thus two “Responsibilities” in the SRP sense.
So to say this again generally, the old wisdom about the purpose of Objects being to hide data behind behavior, especially its implication that this means the same object does both, is a violation of SRP, and is actually more like an OO anti-pattern.
Why should you care?
For all the reasons you’d care about following SOLID principles in the first place. Violating them means that your code will be less adaptable, and communicate its intent less clearly. I’ve personally seen plenty of code that blindly follows this common wisdom – and it bares out the fact that adhering to this lie does us no favors.
But Morpheus’ approach to sharing deep truths like this is very applicable – as with SOLID generally, or TDD, or Agile Principles – one cannot really be told about the matrix – one must see it first hand. So – I would challenge you – find some code that follows the one-object-hides-data-with-behavior anti-pattern. Imagine modeling it, or even try modeling it in a way that separates out the responsibilities, and see if you don’t end up with clearer, cleaner, more flexible code.