[SUMMARY] Clean Code Chapter 6: Objects and Data Structures (Robert C. Martin)

In this Chapter Uncle Bob talks about Objects and Data Structures :

• What are they?
• When to use them? 
• How to use them?

Objects and Object Oriented code

• Private variables
• Public methods
• A maximally cohesive method of a class manages all it’s variables 
• A maximally cohesive class is composed only of maximally cohesive methods
• A class is less cohesive the more getter and setter it has. => Avoid them by using the Tell Don't Ask principal (explained below)
• If we have to use a getter, we want to be as abstract as possible => easier to use polymorphism down the line
• Polymorphism is the key to independent deployability and plugin structure 
• Objects hide their data behind abstractions and expose functions that operate on that data => You will define a Shape interface, with area defined. You can create Rectangle and  Circle classes that will implement the Shape interface
• Object Oriented code makes it easy to add new classes without changing existing functions. => If you want to add a Triangle class, you just have to create it by implementing the Shape class.
• Object Oriented code makes it hard to add new functions because all the classes must change => If you want to add the perimeter function to all shapes, you'll have to add it to the Shape interface and every single implementation.

Data Structures and Procedural code

• All public variables and no methods 
• Data Transfer Objects (DTOs) in their purest form (you use them to translate raw db data into objects usable by the app for example)
• They don’t manipulate a cohesive group of variables, only one at a time 
• They expose implementation, they don’t hide or abstract it 
• You can’t tell a data structure to do anything, all you can do is ask it question 
• Expose their data and have no meaningful functions => You define Circle and Rectangle and you'll have a Geometry class that will calculate the area (using switch statements) .
• Procedural code (code using Data Structures) makes it easy to add new functions without changing the existing Data Structures. => If you want to add a function to calculate the perimeter, you just have to create it in the Geometry class.
• Procedural code makes it hard to add new data structures because all the functions must change => If you want to add a triangle, you will have to add the Triangle case to all the switch statements in the Geometry class.

Active Record

Special form of DTOs created by your db querying tool. They have some logic like find and save.

Do not put business rules in them, you should treat the Active Record as a data structure and create separate objects with business logic and hide the internal data.

Hybrids

If you are not careful you will create hybrids.

Hybrids are classes that acts both as Data Structures (having public accessors and mutators)  and Objects (functions that do significant things)

• hard to add new functions
• hard to add new data

They are the worst of both worlds

The Law of Demeter

A module should not know about the innards of the objects it manipulates.

A method f of a class C should only call

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

Not following the Law of Demeter => train wrecks (long chain of methods called one after the other)

Tell don't ask

When you ask an object for its implementation, you'll risk to violate the Low of Demeter and create train wrecks.

Objects are here to hide the implementation details, to do that you have to tell them what to do, not ask them for the tools to do it yourself. That's the beauty of abstraction.

Conclusion

You should use both Data Structures (direct access to data,  no logic) and Objects (logic, abstraction to access data) !

• Add new data types rather than new functions => Object Oriented
• Add new functions rather than new data types => Procedural

Be sure to tell your Objects what to do without asking for the internals

Be sure to ask the internals of your Data Structures, they should not do anything   

The decision to use one or the other has to be made on a case by case basis by considering how the system might evolve!

For more details and examples, I highly recommend reading the book!

The summaries of the previous chapters are available in my previous posts :)

#cleancode #tdd #cleanarchitecture #developpeur #fullstack