Re: dip Notions 2 Major Errors

From: Ilja Preuß (it_at_iljapreuss.de)
Date: 09/21/04 

Date: Tue, 21 Sep 2004 13:17:55 +0200

Mark Nicholls wrote:
>> It is an observation about one value of subtyping *and* of different
>> techniques that have a similar effect (introducing an abstraction
>> between client and server).
>
> OK, indirection in general, if we restrict to subtyping we wont get an
> explosion of examples.

OK.

>> But the two are still coupled. To get your binary components, you
>> need to compile their source code. If the source code of component A
>> depends on the source code of component B, every time you change B
>> you need to recompile the source code of *both* and are likely to
>> need to redeploy *both* binary components.
>>
>
> hmmmm, this does not seem to be true to me.
>
> components are independenly deployable....and I can version each as I
> choose. if C---->A....I can change A and redeploy just A....given
> that I don't breach the contract.
>
> I did this will dll's, COM and .net.

You are right, of course, that this is possible as long as you are very
attentive and/or have the right tool support. But I haven't yet seen perfect
tool support for this - even the very good incremental Eclipse Java compiler
from time to time decides to recompile all the 80+ projects in my workspace
when I changed an implementation detail in a low level module that shouldn't
have any impact on the clients. Applying DIP to those modules can actually
reduce compile time from several minutes to just an unnoticable moment.

> I accept you need to talk about both, and both are intrinsically
> linked, but we can draw a class diagram and make statements about the
> dependencies in that diagram, and then create scenarios about which
> class is deployed where we can make statements about the dependencies
> in that diagram

Yes...

> ...given the class diagram is fixed.....seperation of
> fixed from variable...i.e. experimental constraints....to allow
> everything to change independently make s any hard conclusions
> virtually impossible to make.

I didn' understand this part at all, sorry. Could you please try to
rephrase?

>>>>>> I agree, but that's not the point of DIP. The point of DIP is
>>>>>> that the concrete A now *depends* instead of being depended upon
>>>>>> by it's callers.
>>>>>
>>>>> logical static again....
>>>>
>>>> The important point is that, while now doing the depending, A still
>>>> *receives* messages.
>>>
>>> And is also depended on by the instantiating client, do not loose
>>> this dependency...it has moved, not gone away or been inverted.
>>
>> It has gone away from the original client.
>
> This is too weak for me.
>
> after the mapping I have demonstrated, I believe it has not.
>
> It is in a different class to that, that operates via the interface.
>
> It may be in a different package from that that operates via the
> interface.

Yes. In many situations, that's a big, important improvement.

>> That's the important part - the
>> high level implementation of the client doesn't care any longer
>> about what low level service implementation it is using, nor where
>> it is coming from. It might not even be decided upon by code I
>> write; for example when using JAXP, to get a SAX parser I just call
>> a method on a factory - which implementation I get depends on what
>> features I requested and what implementations are available at
>> runtime (which jar files are in the classpath).
>
> But the need to be available....so there is a logical dependency.....
>
> There is no compile time package dependency...but there is a run time
> package dependency.

But not on a *specific* implementation. The client (that is the high level
rules) can actually be reused with different low level implementations.

>> In fact this is what the DIP is about: inserting a point of
>> indirection, the abstraction, between high level client and low
>> level server. For DIP it's not important wether you use subtyping or
>> something else to do that.
>
> OK, my irritation with this is simply it's a declaration of
> indirection....which is why I believe Elliott keeps refering to in
> terms of the patterns that support this.
>
> Subtyping is the most common form of this in OO, but I don't believe
> we need to wrap it up in DIP, it obscures the the real message, and I
> believe implies incorrect consequences.

What, for you, is "the real message of subtyping"???

>> Obviously you don't agree on the "inversion" part, but I don't think
>> that's that important.
>
> Probably not, we can agree to disagree on this, I wont loose any
> sleep, and I suspect neither will you.

Correct! :)

>>>> Does that compute to you?
>>>>
>>>
>>> I wish you wouldn't say that....I can never work out whether it is
>>> an insult or a joke.
>>
>> Sorry, I didn't mean it either way - I wasn't aware of the fact that
>> it would typically be interpreted that way... :o
>
> I usually take it as a joke, I am English, and it could be construed
> as a 'are you stupid' or a play on the word 'compute'.
>
> If this group does anything for me, it at least shows me how language,
> especially between different nationalities can be interpreted in
> different ways.

Well, it's probably more an artefact of my imperfect mastery of the english
language... ;)

Regards, Ilja

Relevant Pages

  • Re: Consultant Engineers with ARM processor experience required
    ... especially for low level debugging. ... MP3 player with no requirement to work on the multimedia ... Not necessarily for low level drivers. ... >> The client offices have views of the Alps, ...
    (comp.arch.embedded)
  • Re: Reasons to choose CLISP over other free implementations
    ... This has way more implications for the client than you showed him: ... that guaranty must be of at least 2 years. ... 1.-If the client is the holder of the source code, ... He is not in obligation of assuming responsibility about the service ...
    (comp.lang.lisp)
  • Re: Reasons to choose CLISP over other free implementations
    ... This has way more implications for the client than you showed him: ... that guaranty must be of at least 2 years. ... 1.-If the client is the holder of the source code, ... He is not in obligation of assuming responsibility about the service ...
    (comp.lang.lisp)
  • Re: dip Notions 2 Major Errors
    ... >> In what way do message flow against source code dependencies. ... > Messages flow from client to server without the source code of the client ... >> And is this not just an observation about subtyping, ...
    (comp.object)
  • OT: Contractual issues - Was: Re: Reasons to choose CLISP over other free implementations
    ... This has way more implications for the client than you showed him: ... that guaranty must be of at least 2 years. ... 1.-If the client is the holder of the source code, ... He is not in obligation of assuming responsibility about the service ...
    (comp.lang.lisp)