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



On Jan 25, 8:00 am, "Daniel T." <danie...@xxxxxxxxxxxxx> wrote:
"topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:
On Jan 23, 5:30 pm, "Daniel T." <danie...@xxxxxxxxxxxxx> wrote:
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.Yes, let's look at these two change scenarios and your example.
(http://www.geocities.com/tablizer/bank.htm)

First adding a new plan: In a typical OO solution such a change will
require simply adding a new class. For your solution, adding a new plan
will require modifying 10 different switch statements.

I did not suggest using switch/case statements to model "plans". I
suggested a table(s). If the plans use existing features, then it is
only a table change.


Second, adding a new Feature where each plan implements the feature in a
different way: In an OO solution this would require adding a function to
6 different classes, while in your solution this will require adding a
single switch statement with all 6 implementations in it.

I am not sure what kind of p/r implimentation you are considering. I
evaluated multiple on that page to show different issues.


So, in the OO worst case, I need to add (not modify) 6 functions, in
your worst case, you need to modify 10 switch statements. Add to that
the fact that my worst case is less likely to come up than yours and OO
is clearly the better choice in your example.

This discussion reminds me of something I talked to my teenager about
the other day. I told her that when she is walking through a parking
lot, it is always better to walk behind cars even if it means going
somewhat out of your way. She asked why and I told her that it was
because if you walk in front of them you could get hit. She said that if
they are going in reverse and she walks behind them she could get hit as
well. But I reminded her (as I do you) that (a) cars tend to go slower
when in reverse and (b) cars go forward much more often than they go in
reverse. Take this as a metaphor for our conversation.

If frequency is the issue, I rarely have to modify parallel case/switch
statements in practice. I tend to model things as features, and let the
tables manage which things get which features. What you call "types"
are simply sets of features in my models. Often the programmer does not
have to be involved in assignment of which features go to which sets
because it is done through tables such that an app adminstrator can do
it thru a CRUD screen or an off-the-shelf table browser. The programmer
only has to get involved if a new feature is added. The programmer
controls the *existence* of the feature, but *not* the
taxonomy/classification/assignment of it to domain items. One uses
sets/tables to add such flexibility. DECOUPLE FEATURES FROM DOMAIN
TAXONOMIES/CLASSIFICATIONS.

OO'ers don't seem to get this, and hard-wire such into code out of
habit. There is a book called "Head First Design Patterns" by *four*
authors who claim to be OO experts, in which they *hardwire* Coffee
product taxonomies into the code. This is the crap being taught to our
young. In the future they will laugh at such crap, and OO will be
discredited by association (whether its OOs fault or not).

(Now I will agree that some p/r shops hard-wire stuff in code, but that
is not an inborn fault of p/r. They probably hired some cheap slophead
coder to get it up and running when they were small, and got stuck with
the design.)

-T-

.

Relevant Pages

  • Moving Up the Phone Chain
    ... you carried a cell phone because you wanted to talk ... widely in features, functionality, and cost. ... Nearly all phones are exclusive to a particular carrier. ... where you buy it and what kind of plan you get, says Allan Keiter, ...
    (comp.dcom.telecom)
  • Re: The origins of CL conditions system
    ... I claim that you can benefit from features you don't ... of planning computer programs lies the idea of a contrast ... Coding the routine bits always goes ... When we plan, we lightly sketch in the routine parts of the ...
    (comp.lang.lisp)
  • Re: RFC on other database wrapper modules
    ... Partly for reasons of professional courtesy, I have no plans to single out any of the other solutions for contrast in this talk by naming them; in large part, my solution is designed to exceed deficiencies that I see in all of the other solutions, even the best of those, so it wouldn't be fair to point out one when others are the same. ... Rather, what I will do is outline Rosetta's major features, including in the list both features that people like about other solutions, and features that people want but other solutions lack. ... Note that I have a few large design improvements to make before I actually want input from people, which should come out before OSCON if I have my way, so that any feedback is in the best context. ... I am writing it at this moment, and plan to post it online in a few hours for critiquing. ...
    (perl.dbi.users)
  • its official--cell plans are too complicated (Tilt feature maze)
    ... First problem - voicemail couldn't be set up. ... portion of my plan is PDATETHMICROUNL to the tune of $59.99. ... other lines where messaging works fine... ... rep I talked to tonight, she tried just adding that features, and it ...
    (alt.cellular.cingular)
  • Re: Imaging a WindowsCE 4.2 Xybernaut
    ... We'd have to know what the image is that they're passing to the device to ... modify it. ... The OS had been preconfigured for the client, and a lot of features had ...
    (microsoft.public.windowsce.embedded)