This chapter covers
- Representing records with string maps to improve flexibility
- Manipulating data with generic functions
- Accessing each piece of information via its information path
- Gaining JSON serialization for free
After learning why and how to separate code from data in the previous chapter, let’s talk about data on its own.
In contrast to traditional OOP where system design tends to involve a rigid class hierarchy, DOP prescribes that we represent our data model as a flexible combination of maps and arrays (or lists) where we can access each piece of information via an information path.
This chapter is a deep dive into the second principle of Data-Oriented Programming.
![[Note]](https://drek4537l1klr.cloudfront.net/sharvit2/v-14/Figures/note.png)
Note
DOP Principle #2: Represent data entities with generic data structures
We increase system flexibility when we represent records as string maps and not as objects instantiated from classes. This liberates data from the rigidity of a class-based system. Data becomes a first class citizen powered by generic functions to add, remove or rename fields.
Note
We refer to maps that have strings as keys, as "string maps".
The dependency between the code that manipulates data, and the data, is a weak dependency. The code only needs to know the keys of specific fields in the record it wants to manipulate. The code doesn’t even need to know about all the keys in the record, only the ones relevant to it.