I’ve been reading up on ways to improve my code architecture lately, I’m aiming for an ability to create modularity in my code, so that I can make future changes with as little headache as possible.
I’ve stumbled upon the DCI paradigm and have been enjoying my reading so far. Today I will share the little I’ve learned on the topic, with the intention of writing more posts over time.
What is DCI & It’s Benefits
Before I begin, lets see what wikipedia says about the goals of DCI.
Data, context and interaction (DCI) is a paradigm used in computer software to program systems of communicating objects.
Its goals are:
- To improve the readability of object-oriented code by giving system behavior first-class status;
- To cleanly separate code for rapidly changing system behavior (what the system does) from code for slowly changing domain knowledge (what the system is), instead of combining both in one class interface;
- To help software developers reason about system-level state and behavior instead of only object state and behavior;
- To support an object style of thinking that is close to peoples’ mental models, rather than the class style of thinking that overshadowed object thinking early in the history of object-oriented programming languages.
The paradigm separates the domain model (data) from use cases (context) and Roles that objects play (interaction). DCI is complementary to model–view–controller (MVC). MVC as a pattern language is still used to separate the data and its processing from presentation.
Here’s a snippet from his book, which explains DCI like so:
Separate what is stable from what changes in the interest of good maintenance.
What I Learned Today
When we begin building our classes, they should either represent data (a thing) or model the behavior of a thing, but not both. The more we combine state (an encapsulation of data at a specified point and time) and behavior (the manipulation and/or processing of state data), the more knowledge will be required when attempting to understand one thing.
By controlling our perspective, using DCI we can remove the distractions that aren’t directly related to a particular use case. This basically means that our runtime object isn’t bogged down by unrelated behaviors for the specific interaction.
So if data is a representation of what a thing is, the encapsulation of state. Then context can be thought as the behavior in charge of organizing roles onto our things on a per use basis. This provides us clarity in how we organize our program’s object communication.
When I first started learning MVC on Rails, the controllers were where I would combine state and behavior, but over time began to see a bloating of my controller class files.
Jim’s book says that we can limit our controller’s size and increase the ability to make quick sense of whats going on by simply handling request and responses there and placing our business logic into contexts.
I’m eagerly looking forward to looking at DCI further and making some changes to my current project as I get a better grasp on how to apply this.