Program to an interface, not an implementation

[Gordon Scott]

I found it a little bit helpful to think of 
'program to an interface, not an implementation' as 'treat all objects the
same'

   The Composite pattern of DP is a good example.  The example they give is
of a 
grouping/collection/tree of various GUI widgets.  This might be a common
method
of keeping track of and displaying various windows on a panel.  
   When a widget needs to be updated, various things have to happen for
different 
widgets, a Button needs a button update, an edit field needs an edit update
etc...
One way of doing this is to step though the tree, find out what type of
widget we 
are dealing with and call the appropriate draw function

	for widget in tree:
		if widget.type == button.type:
			widget.drawButton()
		elif widget.type == edit.type:
			widget.drawEdit()
		etc..

Of course this is a poor way to do things, and makes adding new types of
widgets to
the tree extremely difficult.  By programming to an interface, you treat all
objects
the same way by calling the same function regardless of the object.  This is
shown in 
the Composite example by having all widgets implement the Graphic interface
which defines
a single Draw() function that specific classes override.  For C++ or Java
this is done by
having the widgets either subclass the parent Graphic class, or (java only)
implementing a
Graphic interface.  Then the tree does not know whether or not it has
Buttons or Edit fields
all, it is dealing with Graphic objects, so all the tree needs to know is
the Graphic.Draw()
function.  This way you can add or modify specific widgets to the tree
pretty easily.
In python the updated code for drawing all the objects in the Composite
might be

	for graphic in tree:
		graphic.Draw()

MUCH simpler than the above.

   Now comes the beautiful part, Python's dynamic typing.  When the GoF
refers to an 'interface'
it is an abstract term that means 'a set of functions an object implements',
which isn't necessarily 
a concrete thing like a Java Interface is.  
   So for two Python objects to share the same interface, (assume the
Graphic interface) above, they
simply have to have the functions that a Graphic object has, they do not
need to be subclassed from
a common parent or related in any way!!!!  When you say object.Draw() python
simply looks to see if 
that object has a Draw() function, if it does great.  This way you can keep
radically different objects
in your Composite tree and treat them the same way regardless of what they
are, no casting or subclassing
required!  Because of it's dynamic typing Polymorphism is a snap in Python.

  You can see this quite frequently in many Python programs that operate
with 'file-like' objects,
ie objects that have read() and write() operations, and these can be
sockets, files, or StringIO's which are not part of any common class
hierarchy yet the programs work normally with any of those.

Hope that helps...


-----Original Message-----
From: Egbert Bouwman [mailto:egbert at bork.demon.nl]
Sent: Thursday, June 06, 2002 3:12 AM
To: python-list at python.org
Subject: Program to an interface, not an implementation


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 ?
GoF is not easy.
egbert
-- 
Egbert Bouwman - Keizersgracht 197 II - 1016 DS  Amsterdam - 020 6257991
========================================================================


-- 
http://mail.python.org/mailman/listinfo/python-list