Re: Is this the DIP confusion?

From: Mark Nicholls (Nicholls.Mark_at_mtvne.com)
Date: 09/12/04

  • Next message: Mark Nicholls: "Re: dip Notions 2 Major Errors" 
    Date: 12 Sep 2004 05:58:20 -0700

    > >I'm sorry.....this has genuinely been the most constructive post to
    > >date (from the DIP camp) but I still don't see it (and maybe its not
    > >there).
    >
    >
    > What are you trying to see?

    What makes DIP a principle?
    What makes it a good principle?
    Where there is any logical inversion?
    What it has to do with subtyping i.e. why is it considered synonymous,
    except as an application of it?

    My problem is that currently, and I may be wrong, I often am, I find
    it confusing and poor advice, your book, which on the whole is very
    good, is intended I believe to transmit useful information to it's
    users, if DIP does not do that, then maybe you should reconsider it.

    > Perhaps you are imputing more
    > significance than was intended. The principle is very simple and is
    > not meant to be a revolution. Nor do I claim to have invented the
    > concept. Plato (if that's who invented it) is welcome to the
    > copyright.

    It may not have been plato, its in some book somewhere that I now
    cannot find, someone Greek and long ago though.

    Maybe I am, my problem may only be the title and its interpretation,
    "inversion" implies inversion, "principle" implies a generally
    beneficial rule.

    >
    > In a procedural program the modules and functions that contain high
    > level policy depends on lower level modules or functions. The high
    > level modules or function mention the low level modules or functions
    > by name.

    yep.

    >
    > In a well designed object oriented program those low level functions
    > are in a class that *depends* on an interface. The high level modules
    > or functions mention the interface by name but know nothing of the low
    > level modules or functions. Thus the low level modules or functions
    > are not depended upon, bus since they also mention the interface by
    > name, they *do* the depending. That's the inversion.

    for modules - yes.

    "In a well designed" - I think is debatable.

    >
    > Of course this is only at the source code level. At runtime the
    > function calls still go from high level to low level. But the source
    > code dependencies have been inverted.
    >

    At a physical level - yes.
    At a logical one - no.

    I think.

  • Next message: Mark Nicholls: "Re: dip Notions 2 Major Errors"