Objects vs Data Structures

Alon Ronder
4 min readApr 29, 2024

--

From the “Clean Code” book by “Uncle Bob”.

Chapter 6 of “Clean Code,” titled “Objects and Data Structures,” delves into the essence of how we should structure and utilize data in our programs. This exploration is not just about choosing between objects and data structures, but understanding the philosophies that guide their use, ensuring our code remains clean and efficient.

Data Abstraction and Object Anti-Symmetry

The chapter begins with a pivotal discussion on data abstraction. Data abstraction is the art of representing data most simply and robustly. An abstract interface should hide its implementation, not just restate it. This encapsulation ensures that users of the code can manipulate the data purely through its interface, minimizing the risk of errors or misunderstandings.

Closely related is the principle of Data/Object Anti-Symmetry. This principle states that objects hide their data behind abstractions and expose functions that operate on that data. In contrast, data structures expose their data and have no meaningful functions. This dichotomy is fundamental because it influences how we structure systems for changeability and scalability.

Law of Demeter

One of the standout principles discussed is the Law of Demeter, a guideline meant to promote loose coupling in software designs. It dictates that a module should not know the inner details of the objects it manipulates. This “law” is less about strict enforcement and more about reducing dependencies, which can make maintenance and scaling of applications easier.

Data Transfer Objects and Active Records

The discussion extends to specific structures like Data Transfer Objects (DTOs) and Active Records. DTOs are simple objects that should not contain any business logic but serve to transfer data between software application subsystems. Active Records used commonly in frameworks like Ruby on Rails, combine data structures with object behavior, a controversial approach as it blends the boundaries between data structures and objects.

Conclusion: Striving for Clarity and Minimalism

The chapter concludes with a strong emphasis on the importance of clarity and minimalism in code. Objects and data structures should be designed to ensure they are as intuitive as possible. They should not just solve the problem at hand but do so in a way that future developers can understand and maintain.

By mastering these elements of object-oriented design and data structuring, developers can craft software that is not only functional but also clean and sustainable. This mastery leads to code that is easier to debug, extend, or refactor, aligning with the broader goals of software craftsmanship. Thus, the insights from “Clean Code” on objects and data structures are not merely technical guidelines but stepping stones toward deeper software artistry.

--

--