Objects vs Data Structures
This topic is written based on Uncle Bob's post called: Classes vs. Data Structures (2019) and also based on his book Clean Code (2008), in chapter Objects and data structures.
Here I want to point out that it is important to know and differentiate the purpose between an object and a data structure. To facilitate this, we will use the following diagram in which we represent geometric shapes both in the context of objects and in the context of data structures:
| Objects and data structures trying to represent the same thing |
|---|
 |
-
Objects: On this side, we notice that the implementations keep their attributes as private. Here it is easy to add new types without having to modify existing functions. For example, if we wanted to add the Triangle shape, we would only have to implement it from Shape, and the encapsulated data would be the base and height needed to calculate the area. However, it is difficult to add new functions to an existing set; for example, if we wanted to add the
perimeter()function in Shape, we would have to make changes to each of the existing shapes to implement that function. -
Data Structures: On this side, it is difficult to add new types of figures using only data structures, since it would imply making changes in each corresponding function. For example, if we want to add a new type of shape, such as a Triangle, it would be necessary to modify the
area()function. However, it is easy to add new functions; for example, if we wanted to add theperimeter()function, we would simply add it to Shapes, without generating major inconveniences.
So according to the above, we can deduce that the two elements or concepts are opposites, and therefore we can reach these conclusions:
| 📦 Objects | ℹ️ Data Structures | |
|---|---|---|
| Description | It is a set of functions that operate on encapsulated data elements, displaying behavior and hiding their data. | It is a cohesive set of data elements that lack significant behavior, generally used for data exchange. |
| Detail | It is easy to add new types without changing existing functions. However, it is difficult to add new functions to an existing set. | It is easy to add new functions, you just add them. However, it is difficult to add new types, because you have to change each function. |
| Examples | Presenter, Use Cases, Business Entities, etc. | DTO, database tables, models, etc. |
In a clean architecture, when it is mentioned that data structures lack meaningful behavior, it does not mean that they have no methods, but that their methods are limited to interacting and manipulating the stored elements rather than performing specific actions. For example, other data structures such as arrays, linked lists and hash tables contain methods, but these methods are designed to facilitate the interaction and manipulation of the stored elements; that is, their methods lack meaningful behavior.
Here are some examples of simple data structures:
| Example 1 | Example 2 |
|---|---|
 |
 |
| Example 3 | Example 4 |
|---|---|
 |
 |
Therefore, from the previous description and the examples shown, the following can be distinguished:
- In example 2, there is a method that returns the same data structure with default values.
- Example 4 is curious, as it could be considered more like an object because its attributes are private; however, it is not because it does not provide any behavior and the available methods are only intended to interact with its elements. In general, it is recommended to avoid using this way.
- Data structures must not contain dependencies on objects. Instead, they may have dependencies on other data structures (although it is suggested to keep it as simple as possible).
- In all cases, data structures should not have methods that convert from one format to another, as they do not function as a Mapper.
