Re: dip Notions 2 Major Errors
From: Universe (no email)
Date: 09/19/04
- Next message: Universe: "Re: Why Software Is Bad and What We Can Do to Fix It"
- Previous message: Universe: "Re: dip Notions 2 Major Errors"
- In reply to: Ilja Preuß: "Re: dip Notions 2 Major Errors"
- Next in thread: Mark Nicholls: "Re: dip Notions 2 Major Errors"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 19 Sep 2004 15:55:23 -0400
"Ilja Preuß" <it@iljapreuss.de> wrote:
> Mark Nicholls wrote:
> >"Ilja Preuß" <it@iljapreuss.de> wrote:
> >>
> >> But your use of the word "it" makes me think you
> >> are focussing on the dependency leaving C. I agree that this
> >> dependency has not been inverted. What *has* been inverted is the
> >> dependency that used to point to A.
> >>
> >> C--->IA<-----A
> > this about the direction of an arrow on one *logical* dependency as
> > apposed to a completely different one....
> It is, as above, about messages, while still flowing from C to A, now no
> longer only flowing with source code dependencies. Between IA and A, message
> flow is inverse to the source code dependency.
RCM says the "inverse" is of the former relationship from C to the
server. But in fact C still physically depends upon some aspect of
the server. The server doesn't have an inverted relationship to C.
And who cares about what should logically be considered an *intra*
server relationship? That has zip to do with the dependency flowing
from C upon the entity it requires service(s) from.
> Yes. And because we introduced the subtype relationship and don't let the
> client depend on the subtype, messages from the client to the server no
> longer only flow in the direction of source code dependencies.
Sure they do. The C to server dependency is STILL from C upon the
service provider.
> That's the heart of DIP.
Because the key client C to service relationship remains from the to
the service provider, that is why dip is a water muddying, conflated
waste of time.
> The important point is that, while now doing the depending, A still
> *receives* messages.
>
> If I'm understanding the terms correctly, the dip is about decoupling the
> direction of physical relationships from the direction of logical dynamic
> relationships. I don't think it is possible to understand the dip by looking
> only at one type of relationships.
But C is STILL doing physical depending upon the service provider
just REDUCED a la the Strategy pattern.
"Summary
The Strategy design pattern embodies two fundamental tenets of
object-oriented (OO) design: encapsulate the concept that varies and
program to an interface, not an implementation. In this article, David
Geary shows how to use the Strategy pattern to implement an extensible
design. (2,000 words; April 26, 2002)"
From:
http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html
Elliott
-- "'Business priority' in the absence of considering the synergies/dependencies between features is meaningless. Prioritizing a list that you haven't fully reseached and assembled is simply creating an illusion of rigour." ~ Cy Coe
- Next message: Universe: "Re: Why Software Is Bad and What We Can Do to Fix It"
- Previous message: Universe: "Re: dip Notions 2 Major Errors"
- In reply to: Ilja Preuß: "Re: dip Notions 2 Major Errors"
- Next in thread: Mark Nicholls: "Re: dip Notions 2 Major Errors"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
