Re: graph of behavior - was Re: State vs. Data (was Re: Fans of Template Method with protected variable?)

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

Date: 10 Sep 2004 07:52:16 -0700

> expanded from Mr Martin....
>
> > package a;
> >
> > public class A
> > {
> > public void f(IB b)
> > {
> > b.g();
> > }
> > }
> >
> > interface IB
> > {
> > void g();
> > }
> >
> > package b;
> >
> > public class B implements a.IB
> > {
> > public void g()
> > {
> > ...
> > }
> > }
> >
> > Thus [a]----->[b] was changed to:
> > [a]<-----[b] without changing the flow of control.
> >
>
> There is something even more fundamentally flawed with this.
>
> In the example in you book you show 3 layers so in fact
>
> interface IB
> {
> void g();
> }
>
> should read
>
> interface IB
> {
> void g(IC c);
> }
>
> but where is the definition of the interface IC, by DIP it should be
> in the client of the implementations of C i.e. package B so A must
> reference B - *****contradiction****** A now depends on the
> implementation of the interface IB
>
> I belief that is a general ***proof*** that DIP is self contradictory
> in systems with more than 3 layers (and interfaces that operate on
> 'lower' levels, as in your example).
>
> not only does it contradict DIP it also usually impossible as it
> creates a circular reference between A and B.

I think it may be actually worse than that......

If the whole architecture of the software has been defined by the DIP
principle, now actually the methods of the interface can contain
***no*** parameters that reference an interfaces or implementations of
types defined in a lower level, because doing so would create a
circular module dependency.

So that's a pretty strict limitation.

So in a pure DIP world you could only reference data types defined in
a higher layer!

and you need an all seeing god.

and you this god must violate the very principle on which your
architecture is based!

formally.....

The set of integers starts at 1 and we inductively work upwards.

starting at an arbritary n and working downwards does not work, as DIP
attempts to do....

see

http://mathworld.wolfram.com/PrincipleofMathematicalInduction.html

and

http://mathworld.wolfram.com/PeanosAxioms.html.

Relevant Pages

  • Re: pls clarify important concepts...
    ... >>methods in that interface.. ... > public class MyClass implements MyInterface { ... > public void myMethod() { ... > public class UserDaoJDBC implements UserDao { ...
    (comp.lang.java.help)
  • Re: pls clarify important concepts...
    ... >methods of this interface if I implement ServletRequest? ... public class MyClass implements MyInterface { ... public void myMethod() { ... public class UserDaoJDBC implements UserDao { ...
    (comp.lang.java.help)
  • Re: Generics
    ... type and implement a interface. ... public void DoIt() ... public class SmallCar: BaseCar, IDoSomething ... //I want to hold a list with cars, ...
    (microsoft.public.dotnet.languages.csharp)
  • Generics
    ... type and implement a interface. ... public void DoIt() ... public class SmallCar: BaseCar, IDoSomething ... //I want to hold a list with cars, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Speed of interfaces vs inheritance
    ... implementation of an interface. ... Another thing to note is the degree of actual polymorphism at the call site. ... But that kind of optimisation makes considering call sites difficult. ... abstract public void abstractCall; ...
    (comp.lang.java.programmer)