|
Re: The DCI Architecture: A New Vision of Object-Oriented Programming
|
Posted: Mar 22, 2009 8:33 AM
|
|
@By the way, I have no idea what a "problem domain analysis class is." Can you be more precise?
Thanks, a common vocabulary is important.
An analysis class captures some indivisible aspect of the problem domain. Great examples of analysis classes are in Fowler's book Analysis Patterns.
@Yes. A Use Case is a contract between an end user and a system under construction. Too many programmers take this beyond analysis into design. The Use Case ends up being pseudo-code that over-constrains the ordering of processing as well as other design choices. A Use Case should focus on "what," not "how."
The benefit of a use case is it is something both the user and engineers can understand and agree upon.
The benefit of a framework is it is something you can use regardless of small details captured in use cases. In that sense, at some point you need to talk about making sausage-things the user doesn't care about. If you get your gross application structure wrong, then there is no way you are going to stabilize design. A designer-developer facade is also focused on "what", but leaves out implementation details such as perhaps using "nerd-centric" state machines.
The classic example of this is the Browser. The idea that you have a client responsible for negotiating formats with a server and also responsible for knowing how to render those formats is anti-OO. Actually, this is a point Alan Kay makes very clear in his 1997 OOPSLA speech The Computer Revolution Hasn't Happened Yet.
@Are you seriously going to put something other than the system in your problem domain analysis?
Well, that's what I do now. I don't say "The system displays valid accounts", because a System object is way too vague to assign responsibilities too? Moreover, intuitively, it has a "God class" feeling to it.
I am suggesting that you are backing yourself into false premises with statements like these in your article:
@Unfortunately, object orientation hasn't fared so well to capture how we reason about doing. There is no obvious "place" for interactions to live, either on the GUI or in the code. There are exceptions to this rule, particularly for simple actions that involve only a single object.
In practice, you are very, very, very correct in describing how most people write their OO code. But they're also sharing too many implementation details, which is obviously counter to OO. If you want to tell me that traits are a way to provide syntax so developers STOP their bad practices and finally practice the 00 oaths, then that is different. You and I both know compiler syntax features are important, because we can't expect the average developer to be a compiler writer and invent great DSLs -- it's been tried in the past and doesn't work.
I fully understood your point, here, and it is a really hard one to explain -- which is why I'm pushing you so hard. However, there is absolutely a place for interactions to live.
I'll give you examples of things I see as OO anti-patterns that may better illustrate your point. Presentation-Abstraction-Control is an architectural pattern like DCI and intended to address issues such as multi-object interaction. However, the pattern is ultimately ad-hoc case statements (that is what the Control object does at every layer). Yet, it is pitched as "MVC for multi-object interaction".
Another thing you can consider pedagogically is borrowing examples from your competitors. You shoot down state machines as being "nerd-centric", so hopefully you are well-read on the classical examples in FSM literature. However, I'll point them out to you: Ian Horrocks' book Constructing the User Interface presents several examples, beginning with non-OO VB code representing the interactions for a calculator. He then discusses how a HSM can clarify requirements and eliminate bugs. This example was copied by Miro Samek in his two Statecharts books, and he calls it The Ultimate Hook pattern. http://www.state-machine.com/devzone/Pattern_UltimateHook.pdf
Something similar to role-based modeling is Karl Lieberherr's Demeter Tools. All you have to do is write propagation directives targeted at what a Scala developer might call a "case class". In addition, because Karl uses a parts-centered object model that is easier to type-check and express parts-invariants, it is possible to specify business rules (albeit not so clearly, but that is an artifact of not taking the idea to its logical conclusion).
|
|