Re: Exposing Business Layer Objects to Presentation Layer

Discussion in 'Java' started by Universe, Oct 24, 2003.

  1. Universe

    Universe Guest

    "Universe" <> wrote in message news:...

    > ....
    > RCM errantly believes that most systems outside of, and prior to, the
    > current heyday of OO chiefly had physical dependencies that "flow" in a
    > "downward" direction. This is wrong.


    > RCM errantly believes that

    ** the dependnecy problem with of **
    > most systems outside of, and prior to, the current heyday of OO

    ** is that their physical dependencies **
    > "flow" in a "downward" direction. This is wrong.


    ** Actually **
    > we *wamt* most ** of ** both logial and psjhycal dpemncty to flow
    > *downward* to generally achieve the msot optimal system design taking into
    > account the key OO and other sw enineering design factors across all **

    major fronts of consideration.

    The primary problem with dependency in most non-OO layered systems is that
    without *support* for polymorphism and its bigger brother
    "substitiutability" in general it is difficult to build in the degree of
    flexibiltity, extensiblity, robustness that is required for the kind of top
    performing layered systems it possible to build into OO based layered
    systems.

    The major directions of both logical and physical dependency in the best
    designed OO layered systems remain the same as with non-OO layered systems.
    It's just that the crucial interaction points and nodes for OO systems have
    the benefit of *support* for incorporating both polymorphism and
    substitutability.

    The major dependency direction must remain the same otherwise we end up with
    the absurdity of lower layers that can not run if a suitable higher layer
    has not also been constructed to work with the lower layer.

    [Of course what's lower in one context is higher in another and "versa vice"
    [sic, I know :- ], but that's another string of threads. And I've
    previously addressed same in posts of from 2 to 10 years of comp.object gone
    "toodles" :-

    See 'ya for now,

    Elliott
    ----------- End this 'un

    [Booch and RCM are]
    > Stuck one aspect - class type strcuture (vs myraid of other places

    physiacl
    > dependnecy is generated in a system) - of one aspect - physical dependency
    > (vs logical). This stems from their super conservative, pradgmatosm.

    Blind
    > or hard to see the logical and blind or hared to see nathing oheer thab
    > inheriance dependencgt withn pshyical dependcy. It's a shame and itgs a
    > shame given their opiurtunims that hoes hand in hand owht theor ugly,

    ultra
    > reattgionary progamntism. Exists tin a;ll fields and in sofwtare

    enginerin
    > it's called "Craftistry".
    >
    > Sorry about typos will clean up later.
    >
    > Elliott


    ** from an a larger, overall **
    > > system perspective it would be ridiculous to have most system

    dependency
    > > flowing upward as RMartin's harmful and confused 'dip' (he calls the
    > > dependency inversion principle) would have it.

    >
    >
    > > > If most system dependency flowed 'upward' it would be *impossible* to
    > > > compile and link and get *any* lower layers operating before *some*
    > > > suitable higher layer had been compiled and linked. Think about it.
    > > >
    > > > We want to have say our systems' number crunching engine able to get
    > > > going *before* we had to have a suitable higher layer UI, or
    > > > Presentation layer operating. But Robert Martin's 'dip' stresses that
    > > > we want a system's lower layers to physically depend (to compile and
    > > > link) upon higher layers! For RCM, *that* is the a cornerstone of the
    > > > "proper" handling of OO dependency. I hope now that more see 'dip'

    > > for
    > > > what it really is, harmful, deleterious, and just downright a stinker

    > > of
    > > > bad software engineering design theory/principle?
    > > >
    > > > Elliott
    > > > --
    > > > *~* Theory Leads, Practice Verifies *~*
    > > > *~* Global Plans + IID (Iterative & Incremental Development) *~*
    > > > --
    > > > Substituting Refactoring For Analysis Modelling and Review
    > > > When Facing Major High Level Design Problems
    > > > Is Like Drawing a Shade When Totally Dark
     
    Universe, Oct 24, 2003
    #1
    1. Advertising

  2. Universe

    Universe Guest

    "Universe" <> wrote in message
    news:c68c6$3f988089$428681a5

    > RCM errantly believes that ** the dependency problem with of **
    > most systems outside of, and prior to, the current heyday of OO
    > ** is that their physical dependencies ** "flow" in a "downward"

    direction.
    >
    > Actually we *want* most logical and physical dependency to flow
    > *downward* to generally achieve the most optimal system design taking

    into
    > account the key OO and other sw engineering design factors across all

    **
    > major fronts of consideration.
    >
    > The primary problem with dependency in most non-OO layered systems is

    that
    > without *support* for polymorphism and its bigger brother
    > "substitutability" in general it is difficult to build in the degree

    of
    > flexibility, extensibility, robustness that is required for the kind

    of top
    > performing layered systems it possible to build into OO based layered
    > systems.
    >
    > The major directions of both logical and physical dependency in the

    best
    > designed OO layered systems remain the same as with non-OO layered

    systems.
    > It's just that the crucial interaction points and nodes for OO systems

    have
    > the benefit of *support* for incorporating both polymorphism and
    > substitutability.
    >
    > The major dependency direction must remain the same otherwise we end

    up with
    > the absurdity of lower layers that can not run if a suitable higher

    layer
    > has not also been constructed to work with the lower layer.
    >
    > [Of course what's lower in one context is higher in another and "versa

    vice"
    > [sic, I know :- ], but that's another string of threads.


    And the varying contexts for a layer often occur in the same system,
    where a single middle layer has both a layer above and below it.

    Thus a properly built layer generally *depends* on services from layers
    below it, while *providing* services to layers above it. With each
    layer designed that way, overall a system's physical dependency flows
    downward while a system's logical purpose and reason for being (raison
    d'etre) flows upward. The purpose for a single layered agglomeration of
    layers is found at the *top* of system as expressed in topmost User
    Interface--be the "user" a person, or non-person process.

    Elliott
    --
    *~* Theory Leads, Practice Verifies *~*
    *~* Global Plans + IID (Iterative & Incremental Development) *~*
    --
    Substituting Refactoring For Analysis Modelling and Review
    When Facing Major High Level Design Problems
    Is Like Drawing a Shade When Totally Dark
     
    Universe, Oct 24, 2003
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Learner
    Replies:
    5
    Views:
    645
    Karl Seguin
    Dec 21, 2005
  2. et
    Replies:
    2
    Views:
    1,930
  3. dan
    Replies:
    25
    Views:
    1,341
    Uncle Bob (Robert C. Martin)
    Oct 28, 2003
  4. Ily
    Replies:
    2
    Views:
    347
    Robert Haken [MVP]
    Oct 13, 2006
  5. Dhananjay
    Replies:
    1
    Views:
    1,131
    sloan
    Dec 18, 2006
Loading...

Share This Page