Re: Using one design class to manage each use case?
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 10/31/03
- Next message: Uncle Bob (Robert C. Martin): "Re: Separation of gui and business layer: Duplication of data necessary?"
- Previous message: H. S. Lahman: "Re: Newbie Modelling Interface Question"
- In reply to: Ken: "Using one design class to manage each use case?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 31 Oct 2003 19:57:49 GMT
Responding to Ken...
> Any opinions would be greatly appreciated!
In the shower this morning I had another insight into this than what I
already said on the subject. Alas, I like the idea of mapping controller
classes to use cases even less now. B-)
Assume that you are doing feature based incremental development and that
each of your features can be mapped into a single use case. So you
fully implement one use case at a time. What do you do when you
increment a new use case against an application that has already had
several implemented?
It seems to me that creating a new controller class for each use case
would tend to add clutter to the application. In addition, I would
expect it to introduce redundancy if the use case was similar to
previous use cases.
I would think a much more natural approach (from an OO perspective)
would be to abstract classes from the problem space initially and then
enhance them in each iteration by abstracting any new responsibilities
they might need. Then one would only need to add a class if the feature
needed a responsibility that was not logically associated with any of
the existing classes.
For example, consider the traditional banking customer transactions of
deposit, withdrawal, and balance check. That would be three use cases
but one can easily envision processing that only involved a Checking or
Savings Account class (assuming things like persistence and general
ledger functions were handled in other subsystems). Each of those
transactions would likely be a use case, but is there a need for more
than one Controller (Customer)?
I don't think so. OTOH, if the bank starts to allow stock market
transactions from an ATM, then that use case would probably require a
new class. But that class (e.g., Broker Account) would be abstracted
from the problem space based upon the needs of the new requirements to
be resolved (i.e., the traditional Checking Account and Savings Account
would be apples vs. oranges compared to Brokerage Account).
It seems to me that one of the goals of OO is to use abstraction, etc.
so that one can <later> easily modify /existing/ classes to deal with
changing requirements. If one maps use case = <unique> controller class
the intrinsic structure of the problem space gets shuffled aside for an
inherently hierarchical view of the use case as a sequence of
operations, which is a very procedural perspective.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH
- Next message: Uncle Bob (Robert C. Martin): "Re: Separation of gui and business layer: Duplication of data necessary?"
- Previous message: H. S. Lahman: "Re: Newbie Modelling Interface Question"
- In reply to: Ken: "Using one design class to manage each use case?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
