Opinions on this: API's and inversion principle (DIP)

[Gian Franco]

Hi,

Following an off-line lively discussion ,
I would like some opinions on the following
statement:

"APIs, like the Servlet API, are inextricable
linked to the (dependency) inversion design
principle"

The part in the discussion that advocates this
statement thinks that API's are a result of
separating responsibilities and subsequently
reusing them through appropriate interfaces,
independently of their implementation. Therefore
explicitly or implicitly designing by the DIP.

The part in the discussion that denies this statement
sees the DIP as a solution to design problems, for
example of cyclic dependency, but not as a fundamental
characteristic of APIs.

May I have some discussion here as well?

Cheers,

Gian
[ November 21, 2004: Message edited by: Gian Franco Casula ]

[Jeanne Boyarsky]

I don't think DIP is a fundamental property of APIs. However, I do think it is a fundamental property of some APIs. These are the properly designed APIs that are more flexable.

For example, the ArrayList class has an API that has nothing to do with DIP. The Servlet and Observer APIs user interfaces and then work with DIP.

[Stan James]

Java has a couple interesting layering effects. Sun owns the API for JDBC that we use to write applications. The dependency is application -> Sun. Sun also owns the API that database vendors must use to write drivers. The dependency is driver -> Sun. No matter how you draw your layers, one of those arrows is going down and the other up. Is one of them dependency inversion?

Something that hit me with big significance was two ways of thinking about layers. For years we drew Presentation -> Business -> Data. The business layer cannot depend on presentation, so that we can plug in new presentation layers. That actually worked out well. We have business services that are called by Java fat clients and by web clients.

Then I saw Robert Martin's picture of Policy <- Mechanism <- Utility. The part of the program that knows business policy should not depend on the mechanism. In one of his examples a thermostat knows the policies that should be carried out when the temperature goes up or down. It should not be dependent on what kind of thermometer or furnace we use. The trick is for the Policy to own interfaces that the Mechanism must implement. I'd vote for DIP there.

See how this fits the JDBC design? My business services depend on the stable API of JDBC. But when JDBC sets a policy, say "rollback", and a driver is the mechanism, the driver must depend on the (other) stable APIs of JDBC.

Kool.

[Gian Franco]

I agree that not all APIs have been designed with the DIP in
mind, it would be interesting to see if these are considered
well designed APIs and why.

Thing is, as R.Martin puts it, the DIP principle describes
the overall structure of a well designed oo application, and
when the principle is adhered to, high and low level modules
will be reusable and maintainable.

APIs are low level modules with their own lifecycle that
preferably shouldn't influence higher modules.

So to put it in a different way, APIs theoretically would
have the DIP as a fundamental property, in practice some
haven't.

What do you think?

Cheers,

Gian
[ November 21, 2004: Message edited by: Gian Franco Casula ]

[Ilja Preuss]

Originally posted by Stan James:
Java has a couple interesting layering effects. Sun owns the API for JDBC that we use to write applications. The dependency is application -> Sun. Sun also owns the API that database vendors must use to write drivers. The dependency is driver -> Sun. No matter how you draw your layers, one of those arrows is going down and the other up. Is one of them dependency inversion?

Yes. Without the JDBC abstraction layer, the dependency would be application -> driver. Now only look at the arrow on the driver side. The driver has an incoming dependency. Now, if you introduce the JDBC interfaces, suddenly the driver has an outgoing dependency - the direction of the dependency on the driver has been inverted. That's were the name of the DIP is coming from.