Why? What alternatives would you suggest? The narrative appears to fill a gap in OO thinking and seems reasonable enough to invest time and effort in applying it to future efforts.
I use this pattern occasionally, though only when there is sufficient complexity to justify it. I see it as a tool similar to CQRS or hexagonal architecture. It is a way to manage complexity in a more maintainable manner that is easier to reason about and test.
I'll often use it when building out tasks and services, where a simple model (data) is passed into a service (context) and interaction/behaviour specific to that task is injected into the model. In Ruby I'll typically use refinements to do this.
The primary purpose of this approach is avoiding model bloat in my code by being able to decompose additional complexity over time in a flexible way.
If you're interested in getting into DCI more deeply you might want to check out Jim Gay's "Clean Ruby" book (http://clean-ruby.com/)
IMO: This may be one of the important papers to read (also the link within it) because it gives such a good perspective on things. "Some sees the the Model View Controller model as some observer patterns, while it really is to map the datamodel of the program onto the users mind model" It provides a great perspective.
5 comments
[ 4.3 ms ] story [ 20.3 ms ] threadI'll often use it when building out tasks and services, where a simple model (data) is passed into a service (context) and interaction/behaviour specific to that task is injected into the model. In Ruby I'll typically use refinements to do this.
The primary purpose of this approach is avoiding model bloat in my code by being able to decompose additional complexity over time in a flexible way.
If you're interested in getting into DCI more deeply you might want to check out Jim Gay's "Clean Ruby" book (http://clean-ruby.com/)