Clean Code Chapter 6: Objects & Data Structures
Periodically I’ve been posting updates as I read through Clean Code by Robert Martin. I’ve posted summaries on his chapters about Naming Variables, Functions, and Comments. All of this info has been super helpful and I’m 100% sure that this is a book I’ll be returning to as I progress on my coding journey.
These posts are an effort to get the word out about this awesome book, but also to help me solidify some of the concepts in my mind so I won’t forget them. Hopefully this is helpful and feel free to recommend any other helpful software publications!
“Everything is an object” is something I heard when first beginning my program journey and I had no idea what it meant. I was told I would understand one day… but sometimes I’m still not sure I do.
This book does a great job of explaining some important CS topics and how the best programmers handle them, and so I was glad to see Objects would be covered in this chapter ( which it was).
But first, we should talk about Data Abstraction, another concept that has always been… abstract to me.
Data Abstraction
The concept of abstraction has come up in my intermittent readings of CS topics, and this chapter explains it in a pretty clear way.
Users should be able to manipulate the essence of the data generated by data structures, without having to know its implementation.
Basically, we want to try to hide the specific workings of our objects by utilizing variables and object or function wrappers, so that our data is the only thing that shines through. The process of wrapping things up in this way is called abstraction.
Data/Object Anti-Symmetry
That’s not to say that functions should be hidden from the rest of a program. According to Clean Code, objects can (and should) expose functions that operate on their data.
But data structures are the opposite. They should expose their data and not have meaningful functions (aka behavior).
Data structures make it easy to add new code without changing existing data structures. OO code, conversely, makes it easy to add new classes without changing existing functions.
For this reason, programmers designing larger systems will favor using more data structures if they need to give themself room to later develop more OO code, and vice verse if the program may need a more robust data infrastructure down the line.
This all probably seems like a double standard: what’s good for data structures is not good for objects, and vice versa. Data structures and objects play two diametrically opposed roles in the ecosystem of a program. This double standard is what the author means by “anti-symmetry.”
The Law of Demeter
This is all well and good (if a tad bit on the conceptual side) — but is there something saying we absolutely need to wall off our objects using abstraction?
According to Clean Code, it turns out there is. This is known as the Law of Demeter.
The Law of Demeter: An Object should not know about the innards of the objects it manipulates. (If you don’t know, now you know (you know, you know).)
Basically, the law of Demeter means that a method/function should only call methods that are:
- In its own class
- Created by itself
- Passed as parameters to the function itself
- Held in an instance variable of the class
In other words objects should:
“Talk to friends, not to strangers”
Whenever possible, data structures should have public variables and no (meaningful) functions. Data transfer objects, aka data structures with public variables and no functions, are one extreme example of this.
Objects, on the other hand, should have private variables and public functions.
Objects expose behavior and hide data, while data structures expose data and have no significant behavior.
In this respect, the idea that everything is an object is a bit of a crock. Because objects are objects. And data structures should be written simply to provide the information that objects act upon. In other words, data structures should be written to be data structures.
Programmers should also avoid creating a hybrid structure where they mingle the two due to indecision or ignorance of these best practices.
This is all a lot to take in and pretty heady stuff, especially someone who is fairly new to programming. Reading this over, however, I was struck with the fact that the author uses Java as the example language throughout.
How do these concepts of public and private data get handled in a language like Python… is there an analogy, or should I be looking past this particular information?
I’ll be investigating this tomorrow, but in the meantime, I highly recommend checking out Clean Code (and paying an indie bookstore for your copy!).
