Re: Programming to an Interface

Responding to GoogleEyeJoe...

Basically I agree with May's response. I think the problem you are having with it is related to the point Daniel T. made that you are thinking about it at too low a level of abstraction (i.e., the mechanics of the OOPL de jour rather than as a design issue).

- Defining the interface encourages you to think in terms of the
behavior you need to provide rather than how to implement it.


Isn't this inherent in the design of the classes anyway? I mean, you
don't create methods on class without first thinking of the reason
behind having the functionality. Isn't this one of the things to do
when outlining what the class is for, i.e. what should its inputs and
outputs be...

I think the point here is that one designs the interface first and then the implementation. Doing the interface first sets the overall problem context. One can abstract most problem space entities in any number of ways but there will usually be only one best way to abstract them for a given problem context. Doing the interface first forces one to think about the entity's intrinsic properties in terms of what the problem solution needs for collaborations.

It is no accident that all OOA/D books define objects in terms of knowledge and behavior /responsibilities/. Initially one needs to think in terms of What an object knows and does, not How it knows it or does it. Interfaces keep one focused on the responsibility view.

- The implementation of the behaviors exposed by the interface
can be changed without impacting users of the interface. The
implementation selection can even be deferred until runtime.


Is this not the same for methods of an object? Isn't this one of the
advantages of encapsulation. An object's method can be changed
internally (in its functionality) without having a direct impact on the
client of the object. How does implementing an interface differ from a
non-interface method of an object in this respect?

I believe the point here is that interfaces allow one to define responsibilities in terms of invariants, often at a higher level of abstraction than particular implementations. IOW, an interface should be designed to provide as generic a view of the responsibilities as the problem context will allow. The more generic the interface view, the less likely it will be that changes to the implementation will affect clients.

Consider a <contrived> example:

[AccountTransfer]
+ amount
+ sourceAccountID
+ targetAccountID
+ transferCheckingToSavings()
+ transferSavingsToChecking()
....

compared to:

[AccountTransfer]
+ amount
+ sourceAccountID
+ targetAccountID
+ transfer()
- transferCheckingToSavings()
- transferSavingsToChecking()
....

One has identical implementation behaviors for both classes but the interface that the client sees is much more generic in the second case. So when one decides to add transferCheckingToBrokerage() that will be completely transparent to the client. Similarly, one can decide to subclass [AccountTransfer] or employ a GoF Strategy pattern delegation, again all quite transparently to the client. That is only possible because the level of abstraction of the interface has been raised to the more generic notion of 'transfer'. When one is mired down in the business rules to implement this class, the first solution will be the more likely initial cut because it parallels the implementation decomposition.

- Users of the interface are less likely to become coupled to implementation-specific details.


Would this not be the case only if the class was designed badly in the
first instance? Surely, as a designer of a class you would only expose
those parts of the class that you would want the client to use, in the
same way as you would define interface members that you would want
clients to use...?

I don't think so. My example above applies here as well. In the first case the client needs to understand the context that there are differences in the way a transfer is done in order to invoke the correct method. IOW, the client must understand the context and how the implementation deals with it.

In the second case we don't know how [AccountTransfer] figures out which private behavior to invoke. But the client doesn't either and that is a Good Thing. We have moved that decision from the client to where it logically belongs -- in the processing of a transfer.

Note that in this case we have actually changed the way we allocated responsibilities to objects based on the way we wanted to implement the interface. So I would add this to May's reasons: to provide a sanity check on object cohesion and the allocation of responsibilities.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Newbie Modelling Interface Question
    ... >>the first case) or it can access directly through the derived interface. ... > In my case the client is accessing polymorphically. ... was the point of my aside about subsystem vs. class decoupling; ... each with its own responsibilities and then those objects ...
    (comp.object)
  • Re: Disadvantages of Dependency Inversion?
    ... In a language like Java that supports pure interface inheritance, ... [One can also implement DIP with a Facade pattern, ... semantics more broadly and start providing additional responsibilities ... So even though the service interface does not change, the client will ...
    (comp.object)
  • Re: Programming to an Interface
    ... Isn't this inherent in the design of the classes anyway? ... can be changed without impacting users of the interface. ... client of the object. ... found a reason why from programming to interfaces is better than ...
    (comp.object)
  • Re: On the development of C
    ... I've never seen a "list" interface for C that wasn't more work ... Thanks to modern features of the language, I can write client ... sounds like a bad design from the outset. ... I tried the Vista speech recognition by running the tutorial. ...
    (comp.lang.c)
  • Re: How to physically implement a component?
    ... >describing how to physically implement the design. ... >how does a client component make use of a server component's ... Or perhaps the correct question is how does a client ... >object make use of a server component's interface? ...
    (comp.object)