> OK. So what happens is that if the account concept is > involved in 10 use cases of your application, you may end > up placing some behavior for each of those use cases into > class Account. Deciding what behavior to put > in and what to leave out is the designer's challenge. > > DCI challenges the assumption that each object has one and > only one class. The observation is that objects need > different behavior in different contexts. So why not let > an object have a different class in each context? The way > it shakes out is that you will have an anemic > Account class in your design, and different > traits that can be mixed into Account to > supply just the extra (non-anemic) behavior needed for the > use case at hand. And DCI also suggests is that use map > these traits to conceptual roles in the user's thinking. >
Bill, thank you for that explanation.
OK. So what happens is that if the account concept is involved in 10 use cases of your application, you may end up placing some behavior for each of those use cases into class Account. Deciding what behavior to put in and what to leave out is the designer's challenge.
That has always been my fundamental problem with OO languages like Java and C#. Grouping behavior with different contexts in the same class isn't right, but as you stated, what do you leave in and out. Maybe that's why I've always been intrigued with Common Lisp's CLOS style of OO.
Flat View: This topic has 119 replies
on 120 pages
[
«
|
353637383940414243
|
»
]
Previous Topic
