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

From: Universe (no email)
Date: 09/08/04 

Date: Wed, 08 Sep 2004 03:23:54 -0400

Robert C. Martin <unclebob@objectmentor.com> wrote:

> On 7 Sep 2004 01:59:12 -0700, Nicholls.Mark@mtvne.com (Mark Nicholls)

> >This is my problem with the 'inversion' bit, it appears to be
> >counterintuitive, and I think it causes confusion (in me at least)
> >because it only tells half the story.
 
> You aren't the first person to complain about the term "inversion",
> yet it speaks very loudly to me.

Whoops!

SORRY!!

He says he isn't first. APOLOGY!!

> The reason is that by introducing an
> interface, I can invert the dependency between two packages without
> changing the control flow.

>
> package a; public class A {public void f(b.B b) {b.g();}}
> package b; public class B {public void g() {...}}
>
> In this case package a depends upon package b. If I don't like this
> arrangement I can change it as follows:
>
> package a;
> public class A {public void f(IB b) {b.g();}}
> interface IB {void g();}

Here class A depends upon interface IB. PERIOD!!
 
With Strategy and Bridge [which are the mainstream non
"Uncle Bob" sycophant terms for using abstract interfaces to concrete
classes to reduce dependency] while higher levels minimize static
dependency - compilation and linking - on lower levels STILL certain
changes to lower level classes like:
        ~ changing their signature
        ~ changing their interface method order
        ~ changing data member types
all MANDATE higher levels eve depending upon abstract interfaces to
recompile and relink.

Please realize that this is a MAJOR theoretical misstatement and
confabulation by your "Unca' Bob" regarding the Strategy and Bridge
patterns.
 
> 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.

Why should class b depend upon package a at all?

In general it's best to have an abstract interface in its own header
file and have the client incorporate the header to the abstract
interface and have class b SIMPLY the implementation of the interface
incorporate the header to the abstract interface.

RCM places the interface with class a in attempt to deceive us and
make it seem that class a does not have a compilation dependency upon
the interface for class b.

But even though the interface IB is in a package with class a, class a
STILL DEPENDS UPON IB!!!!!!!

> To me, that's an inversion, and an important one. I am always looking
> for ways to manage dependencies between packages. (More specifically,
> between jar files). DIP is a powerful tool in that management.

Every intermediate Java, Eiffel, Ada, C++/C programmer knows that one
should use the STRATEGY/BRIDGE pattern to REDUCE dependence of client
on its servers!!

We don't need DIPS' confused, muddled, and OBSCURANTIST INVERSION
terminology to make things MORE COMPLEX and INTRACTABLE.

Polymorphism mandates that either the whole base class is virtual
abstract, or the polymorphic method calls are virtual in the base and
whatever in between classes.

> >It seems to me that if you consider the dependency tree as a partial
> >ordering and the call tree as a partial ordering
> >
> >if A < B in the dependency tree => A < B in the call tree.
> >if A < B in the call tree => *not* A > B.
> >
> >i.e. no inversion. I cannot have A < B in one ordering and A > B in
> >the other.
> >
> >(I'm free wheeling, but this seems to be correct to me and my scrap of
> >paper).

Right on dude!
 
> As long as we are free wheeling... Imagine that every possible
> communication in the system is done using the Observer pattern.

Such as in the Observer pattern I used to show how it was possible
despite RCM's confusion about how to model and implement real world
domain Part/Whole relationships with minimal dependency between the
parts yet clear leadership by the "Whole" mediating Observer class
itself.

In the past RCM has been averse to Parts *led* by a Whole.

And his aversion is evident right here:

> If any module A communicates with B, it is B that asked for the
> communication.

Balderdash!

Observer allows a part that changes to notify any other parts
interested *by way of the mediating Whole Observer*.

> So, ignoring the registrations, all messages would be
> sent against the direction of source code dependency.

Huh?

> You could even
> work it such that the registrations were all sent to interfaces, so
> that even they flow against the source code dependencies.

Whaaaa....??

> In that
> case the only message flowing with the source code dependencies are
> the calls to 'new' made by main. And even *they* could be eliminated
> if you used enough reflection.

Yeah, shhhrrright!

> In short I think it is possible to set up a runtime graph in which
> every message flows in the opposite direction of the corresponding
> source code dependencies.

How would that be possible. This is smoke and mirrors double talk
here RMartin attempts to awe newbies and other uninformed by "snowing
them" with SOPHISTRY!

Did you know "Sophisticate" is really a backhand slap because the root
is:
        
Sophistry:
        unsound or misleading, but clever, plausible, and subtle argument,
or reasoning

Sophisticate:
        to change from being natural, simple, artless, etc to being
artificial, worldly-wise, urbane, etc.

Sophomoric:
        of, like, or characteristic of being a sophomore, or sophomores,
often regarded as self-assured, opinionated, etc. though immature

> I don't suggest this as a rule, but it
> would be fun to create the example.

Oh yeah, right, lotso fun. Hardee, har, har!!

Elliott 

-- 
"Object-oriented [OO] programming. A program execution is regarded as
a physical model, simulating the behavior of either a real or
imaginary part of the world...The notion of a physical model should be
taken literally."                     ~ Computerized physical models
Madsen, Moeller-Pederson, Nygaard (co-founder of OO)

Relevant Pages