Re: Booch's book feels too philosophical rather than practical?



On Jan 23, 5:30 pm, "Daniel T." <danie...@xxxxxxxxxxxxx> wrote:
"topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:
"Daniel T." <danie...@xxxxxxxxxxxxx> wrote:
"topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:
But you forgot to mention another change pattern: loss of mutual
exclusiveness. If 2+ options change to no longer be mutually exclusive,
then procedural fairs better. It is a smaller change: just change the
CASE to IF statements. With polymorphism you have to move code to
different named modules, and I give that a much higher change cost
score.

An example please.

http://www.geocities.com/tablizer/bank.htm#feeRemember what I said:

If you have multiple case/switch statements all switching off of the
same variable and "those options" change in any way, you have to
change every case/switch statement. If you only have one case/switch
statement, then you only have one place that needs to change.

But the reverse is true for adding new operations to existing
sub-types. There are at least as many change scenarios that can muck up
polymorphism. Generally hierarchical or mutually-exclusive lists of
"types" is poor modeling in my domain so I tend to avoid them up-front
anyhow. Classifications of real things are more complex or local than
that. I check with domain experts to make sure they will stay
mutually-exclusive forever and ever before I create lots of dups.

(The example shown was meant to illustrate the M.E. issue, not adding
new sub-types versus new operations.)


In your example, *every* case statement that made a decision based on
account type would have to change into the "if" version.

It is simpler than the corresponding polymorphism de-mutual-excluding.
At least I am changing a bunch of things in place rather than moving a
bunch of things between named units. You are not considering the OO
ramifications of de-mut-ex on a wider scale.

Also, every
time a new account type was added (a far more likely scenario than
changing the way current accounts work,) every case statement would have
to change. How many case statements are in this code? From the chart, it
looks like there would be 10 of them. That's a lot of duplication in my
book.

And visa versa with new operations to existing types.

-T-

.

Relevant Pages