Re: Disadvantages of Dependency Inversion?



Mark Nicholls wrote:

The object of the exercise would often seem to be to be able to
stratify our systems into layers, and as such would seem to defeat
this objective....something I think you agree with, but seems, for
some bizarre reason, to be matter of debate in this group.

Layering is merely a human cognitive activity, not a quantitative
measure of the utility of something.


But this in a way is to miss the point DIP says absolutely nothing
about how to logically model software (thus my question to the OP), it
is a trivial observation about the nature of physical dependencies on
the operation of moving a logically entity from one set to another
(once we've explicitly seperated interface from
implementation)....there is no logical inversion at all (how could
there be...it would be the equivalent of claiming two formal systems
to be consistent yet one contain a sentence A, and the other contain
it's contradiction (inversion)....clearly this is not possible).

So change the name to : Dependency *Indirection* Principle.


So what is it's practical value....

(1) loose coupling between components?

how?

Indeed.

Use of said "principle" only eliminates one specific coupling problem (and
implicitly I guess - one of the five classic coupling forms known to s/w
engineering) .


in most cases it would seem to create a loop in the physical dependencies.

It creates a bigger component (dependency) graph.
Re the Wheeler quote by Daniel T (about solving any problem via the use of
indirection, and introducing new problems as a result) .

Whether that graph is cyclic or not is another story.


(2) effective and easy testing (component testing or unit testing)?

how?

Indeed.


unless we are simply confusing DI with simple subtyping I don't really
understand it's relavance (or its value).

1. The separation of component specification (interface) and implementation
is a fundamental engineering concept. It allows us to change component
implementations without affecting the users of the component.

2. Building on 1 is type substitutability.
Which allows us to have *multiple different implementations* of a component
*existing concurrently* in a system.


Regards,
Steven Perryman
.