MVC was meant for reflecting the end user’s mental model but it still makes it too easy to hide the intentions of your program in your code.
- It’s hard to find bugs in own code
- It’s fun to find bugs in other people’s code
- I learn from reviewer’s comments
- Reviewer learns by reading my cod
Code must be Chunkable! Readable!
- The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships.
- The run-time structure consists of rapidly changing networks of communicating objects.
You get technology upgrades and everything, but the idea is that the objects that are in your human mind are also in the mind of this computer and should have as seamless an integration between them as possible. That's why Trygve did model-view-controller, to make that link between the memory of the computer and the memory of the human being. Good objects are about capturing the end user mental model in the code, in the program and most object oriented programmers don't think this.
They think what object oriented programming is is encapsulation and coupling and cohesion and polymorphism and interfaces and classes and they completely miss the big picture, which is this about human mental models. Even if we can get that into the mind of the mind of the object oriented programmers into our curricula is being what objects are about and how you find the right objects and then reduce them to classes. That would be a start, but my fantasy would be that we do this at a much larger scale.
The main focus of programmers resides in understanding the mentality and psychology and thought processes of their markets and of the people in their markets, rather than looking for the golden chalice of coupling and cohesion. They have something to do with each other, but the focus should be on the people.
DCI has been created to solve a problem in object orientation: it's too difficult to review OO code.
The code for one use-case in OO is typicall spread out between lots of classes. To understand how the code works, you must also know the relationships between objects in runtime. These relationships aren't set in code, they depend on the situation.
What DCI proposes is that code for a given use-case is separated out from the classes and put into a different artifact called context. Objects of different classes can enter into a relationship in this context and take part in interaction where they have different roles.