Objects play big role in modeling software. Eventually, everything we work with is an object, including data that we need to analyze and make corresponding decisions based on it.
When we look at objects as data holders, it's very important to correctly express different states of the data as objects. This is were Intuitive Object Models come into picture.
Let's consider an example of Data class that holds properties representing two conditions. First condition ("conditional") is always present, and it's either in positive or in negative state. For each of positive and negative states, we are expecting additional parameter to be provided when dialing with data in the given state. Data class's second condition ("positive") can also be in positive or negative state. While for negative state, there is no additional parameter expected, for positive state, we expect to see additional parameter.
To properly solve this problem according to the "intuitive" paradigm, our Data class has two properties, one for each of the conditions. For the first ("conditional") condition, it has mandatory property that is of an abstract ConditionalState type. ConditionalState can be represented as concrete type of PositiveState or NegativeState, each providing property for additional parameter inside them. For the second ("positive") condition, Data class has optional (nullable) property that is of the PositiveState type.
Above diagram demonstrates the implementation of Data class visually. It's intuitive because the following statements apply:
Now you can see the purpose of the term "intuitive object model". It's intuitive since we don't have to guess how the Data class should be interpreted. We just check the values of different properties and make intuitive conclusions based on them. Above diagram shows the pseudo-implementation for the possible Client class.
The object model stops being intuitive once the above conditions mutate into these conditions:
For completeness, I'm demonstrating the non-intuitive (wrong) approach to the object modeling below:
Writing a proper Client for this kind of object model is challenging, and may even require special training or knowledge sharing sessions.
Curious about object modeling, design patterns, and software architecture? Read other articles or consider booking a training course in Design Patterns or other technical topics, delivered by myself.
The author of the above content is Tengiz Tutisani.
If you agree with the provided thoughts and want to learn more, here are a couple of suggestions: