Re: dip Notions 2 Major Errors

From: Roger L. Cauvin (roger_at_deadspam.com)
Date: 09/17/04 

Date: Thu, 16 Sep 2004 19:05:40 -0500

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:9f4kk0tf4qo6ic9st0g6e7h2dq8kq3rd6f@4ax.com...
> On Thu, 16 Sep 2004 13:27:17 +0100, "Mark Nicholls"
> <nicholls.mark@mtvne.com> wrote:
>
> > I should not let my irritation with others stiffle our discussion
> > i.e. if I choose to not engage with Mr Martin until he defines
> > and sticks to a definition of anything then that's my and his
> > problem.
>
> So we've gone from "agree to disagree" to "Mr. Martin does
> not define and stick to definitions of anything."

Here's my analysis of the debate and the terminology confusions. Mark's
primary arguments against the DIP are as follows:

1. There is no inversion in the DIP, except perhaps at the package (set of
classes) level. The reason is that, for any two classes x and y such that
'x depends on y', applying the DIP never changes the dependency so that 'y
depends on x'.

2. To the extent that the DIP inverts dependencies at the package level, it
results in a poor design. Take the button/lamp example. At first, we have
a button package that depends on the lamp package. When we apply the DIP,
we invert the dependency between the packages by creating an interface
(IButtonClient) and placing it in the button package. The lamp package now
depends on the button package (due to the dependency of the Lamp class on
the IButtonClient interface), and the button package no longer depends on
the lamp package. But the IButtonClient interface should go in a separate,
third, package.

3. The DIP doesn't logically invert any of the software dependencies.

I'm going to leave aside argument 3 for now, because I don't fully
understand it and suspect it will be moot if Mark ever recognizes that his
arguments 1 and 2 are misguided.

Argument 1 is correct in its observation that the DIP does not invert
dependencies between any two classes. Mark is right that applying the DIP
doesn't result in 'class x depends on class y' changing to 'class y depends
on class x'. Instead, 'x has an incoming dependency on y' becomes 'x has an
outgoing dependency on z'. These two sentences are not inverses of each
other. What Mark has failed to acknowledge, however, is that the relation
(not the full sentence) in which x participates DOES invert. The relation
in which x participates changes from 'has incoming dependency' to 'has
outgoing dependency'. That's a form of inversion, however subtle. If he
wishes to argue that the article and book don't clearly describe the nature
of this dependency inversion, or that the inversion is so subtle that it
hardly justifies mentioning it, I think his argument would have merit. But
he should at least acknowledge that the dependency inversion exists.

Argument 2 assumes that the DIP aims or claims to invert dependencies
between two packages. This assumption is false. You can apply the DIP at
many different levels of granularity, including at the package or class
level. Sometimes, as in the button/lamp example, the application of DIP
results in an inversion in the dependencies between two packages. This
inversion strikingly illustrates the value of the DIP, but "dependency
inversion" in the DIP does not necessitate this inversion of dependencies
between two packages. The only inversion that the DIP necessitates is the
change from 'x incoming dependency' to 'x outgoing dependency', where 'x' is
a class, package, or other granule of software.

Related to argument 2 is the issue of whether it is better to place the
interface in a separate third package. This issue is tangential to the DIP,
since the DIP doesn't necessitate an inversion of dependencies between two
packages. In fact, placing the interface in a third package is consistent
with the DIP. The button/lamp example was illustrative because it happened
to show an actual inversion of dependencies between two packages. But
placing the interface in a third package would still be an application of
the DIP.

The confusion over the definition of "module" also relates to argument 2.
Mark assumed that "module" was synonymous with "package" and "set of
classes", and that the DIP claims to invert dependencies between two
modules. The DIP's usage of the term "module", however refers to any
granule of software, whether it be a class, a set of classes, a source file
implementing a class, or a group of related functions. The fact that you,
in response to some of Mark's messages, used "module" to refer to a set of
classes does not entail that "module" is synonymous with "set of classes".
Every set of classes is a module, but not every module is a set of classes.
That's Logic 101. Furthermore, the DIP, while it applies to modules, does
NOT claim that its application always and necessarily inverts dependencies
between two modules. The inversion, as I've already stated, is in the
dependency relation. 'Module x has an incoming dependency' becomes 'module
x has an outgoing dependency'. 

-- 
Roger L. Cauvin
nospam_roger@cauvin.org (omit the "nospam_" part)
Cauvin, Inc.
http://www.cauvin-inc.com