Re: Article: Mind Mapping for OOAD

From: Universe (universe_at_covad.net)
Date: 10/27/03

  • Next message: Universe: "Re: Naive, possibly silly question" 
    Date: Mon, 27 Oct 2003 14:56:24 -0500

    "Tobin Harris" <tobin_dont_you_spam_me@breathemail.net> wrote in message
    news:bncb01$vmdcc$1@ID-135366.news.uni-berlin.de...
    > "Universe" <universe@covad.net> wrote in message
    > news:224b9$3f999f32$3f47e403$27275@msgid.meganewsservers.com...
    > > "Lidor Wyssocky" <lidor@QualityProgramming.org> wrote in message
    > >
    >
    http://www.sharpdevelopment.com/MindMapping/MindMappingForOOAD/MindMappingFo
    > > > rOOAD.htm
    > > I get "Page Unavailable" and an ad for an ISP.
    >
    >
    >
    > Did you accommodate the line-break?

    Nope, I didn't and that was the "ticket", mucho gracias.

    Looks compelling from only just getting there and then writing this.

    More proof that the xp/allie/craftite, oh so sharp coder craftsmen" are
    blowing it out of their "[ ]ear" when they declaim that OO is _only_
    about certain principles having to do with managing code dependency.

    What a droll, "lost" mentality and way of seeing the world. It must be
    awful.

    There's no way you can really be the best at OO sw engineering, overall,
    if you don't see OO in the really existing fundamental nature and
    character of the domain for which you are creating OO systems. You
    _may_ be acceptable at OO coding, but can't but come up "a cropper"
    respecting analyzing that domain and creating optimal OO solution
    designs, especially at the high level which should then *drive* *all*
    lower level coding.

    Perhaps this why they oppose the leading role of OO analysis--they are
    incapable thus inept at seeing the domain in OO terms in the first
    place. Naturally like that one would proclaim that OO analysis and
    overall, up-front OO system architectural system design shouldn't lead
    coding.

    Tobes you may think otherwise, but I had to make the evident point and
    hopefully save some from the "soul less", arteriosclerotic path laid out
    by xp/allie/oma/rcm/mf/kb/pj/flip and others. Of 'em all Fowler has the
    most useful to say, but its apparent he also is much handicapped by the
    bloodless, anti-OO is a world view going back thousands of years notions
    they all adhere to. Witness MF's anti distributed OO systems stance.
    Also I believe he's not fond of emphasizing the diff between aggregation
    and decomposition.

    RCM is hopeless. It's very clear to me he likely started coding rather
    then attend college, got into it heavy with Booch where he got the
    formal pragmatist (i.e. anti-Nygaard, anti-Kay) notions that help
    justify his visceral, instinctual anti-OO as a world view thinking and
    practices.

    10 years ago RMartin's logic was a whole lot worse than today. He got
    it a bit better after I, disgusted at having to grapple with his
    convoluted logic in discussion urged him to read a Logic book, or go to
    a Logic course.

    Only someone with a super conservative pragmatism would think that the
    answer to one form of dependency polymorphism was *the* root answer to
    the range of sw engineering problems, beginning with compilation and
    linking - physical - dependency in his view. Ie. he thinks the ability
    to decouple interface from implementation in *inheritance* polymorphism
    is the key to almost every sw engineering problem. Forget that we can
    use *Delegation*. Forget that there is *Logical* not just *Physical*
    dependency to be managed properly. Forget that overall proper solution
    modelling is the leading process for creating optimal - not only OO but
    any paradigm - system design and most sw engineering challenges in
    general. On and on

    RCM with Booch formalized his harmful notions that OO is only a means of
    reversing the direction of dependency in layered/hierarchical systems.
    Which could only come from someone not integrating the big picture in
    his engineering methods and practice. That is why he improperly thinks
    the interface of an a class hierarchy is a solid and hard level *above*
    the implementation code. In fact a class hierarchy interface is at best
    a *sub-layer* above its typically multiple class code implementations.
    And overall physical layered dependency had *better* mostly run
    *"downward"*, or we won't be able to get the lower layers compiled,
    linked and running _ e.g. the Data layer - running before we create an
    interface! RCM's world would have to be horrible in that case. But
    I'll bet he gets many a low level going before an interface, but just
    doesn't *realize* or *see* how it *nullifies* his dip notion.

    And it relates to his single interface in that while it might be nice,
    it's ludicrous to create an interface for *every* client and to think
    this was a fundamental of good OO, or other, system construction. Gee
    if the server changed sufficiently we'd have to find and recompile and
    relink *every* instance of client interface code. It's bad enuff having
    to that for a single interface. But now I have to find Henrietta's,
    Doug's Jamal's, poor Rufus' ;- }, Payroll's, etc interface code and
    recompile/relink all those because RCM in his wisdom thinks each client
    should have it's own interface code due as embodied in his damaging SRP.

    Elliott 

    -- 
      Substituting Refactoring For Analysis Modelling and Review
            When Facing Major High Level Design Problems
                 Is Like Drawing a Shade When Totally Dark
-- 
      Substituting Refactoring For Analysis Modelling and Review
            When Facing Major High Level Design Problems
                 Is Like Drawing a Shade When Totally Dark
  • Next message: Universe: "Re: Naive, possibly silly question"

    Relevant Pages