Program to an interface, not an implementation

[Eric Brunel]

Egbert Bouwman wrote:
> Hello,
> Can someone shed some light on the GoF adagium:
> 'program to an interface, not an implementation'
> and especially what it means for programming in Python ?

The difference is quite simple: for a given class, its interface is the set 
of its public methods, with their syntax (parameters, return value(s)) and 
semantics (what they should perform). In other terms, the interface of a 
class defines _what_ the class should do. The implementation for a class is 
_how_ things are done, i.e. the actual code of the methods, performing the 
"what" defined in their semantics, including algorithms, call to 
protected/private methods, and so on...

For example, for a "sort" method on a list, you may define like in Python 
that it has no parameters, no return value and that it sorts the list "in 
place". This is the interface, i.e. the "what". The "how" will be the 
actual algorithm, which may be any of the well-known algorithms for sorting 
lists.

"Program to an interface, not an implementation" means that the caller of a 
method on a class should only rely on "what" the method should do, not on 
"how" it's done. In the example, it just means that you'll use the "sort" 
method for what it's done (sorting a list), and nothing more. When told 
like that, it may seem quite obvious, but imagine for example that you 
coded the "sort" algorithm and that during this algorithm, you had to set 
an attribute of the list to the list length. If after doing the "sort", you 
use this attribute to get the list length, you're using a side effect of 
your algorithm that should have remained hidden from the outside. That's 
what is called "programming to an implementation": it's *because* your 
"sort" method is coded like you did that you can use the attribute.

In fact, saying "program to an interface, not an implementation" is just a 
way to describe the traditionnal OO concept of "encapsulation": the exposed 
part of a class is its interface; how methods are implemented inside the 
class should remain hidden. The aim of this is to allow future changes in 
the implementation of your class without affecting its interface. In the 
example, imagine that you coded a simple but quite inefficient sort 
algorithm, and that someday, somebody comes and wishes to use a more 
efficient quick-sort: given the interface of the "sort" method, he has no 
way to know that you used the attribute giving the list length. So his 
modifications may break your code if he doesn't set the list length 
attribute anymore.

In fact, I often say that a good OO programmer should be schizoid: the 
person who codes the actual algorithms should not be the same than the one 
who uses them, even if it's the same physical person. You should always 
define the interface of your classes, implement them, then forget 
everything you did during the implementation phase, and finally write the 
code that uses the classes, just looking at the interface you defined in 
the first place.

Hope it's a bit clearer now...
-- 
- Eric Brunel <eric.brunel at pragmadev.com> -
PragmaDev : Real Time Software Development Tools - http://www.pragmadev.com