[Zope] Are "Interfaces" anything more than a documentation mechanism

Phil Glaser StillSmallVoice@DirectvInternet.com
Sun, 25 Aug 2002 16:41:04 -0400


Hi,

I'm reading through the Zope Developers Guide
(http://www.zope.org/Documentation/Books/ZDG/current/index_html) and have a
questions about the whole concept of interfaces and components.

When I first saw this, I thought the Interface module was a way for
accomplishing something similar to what you do with an abstract class in
C++. In C++, you define an interface that has no implementation, so that any
class that inherits from it must implement the interface defined in the
abstract class. Thus any method that operates on the type defined by the
interface doesn't care what the implementation is, and behold you have
information hiding and polymorphism.

My impression about the abstract class nature of the Interface module was
aided and abetted by the following sentences on page 29 of the Developers
Guide: "To turn a component into a product you must fulfil many contracts.
For the most part these contracts are not yet defined in terms of
interfaces. . . ." This statements makes it sound as is there is something
architecturally significant about the relationship between a component and
its interface.

However, after having studied the Developers Guide more closely, and playing
around with some examples at the interpreter prompt, it seems that the
Interface module does nothing of the kind. There is no enforcement -- no
mechanism for raising an error if a component that claims to implement an
interface does not do so entirely. For example, if I add a method to the
interface that is not implemented by the component,
isImplementedByInstancesOf() still returns true.

On the other hand, there is a rich set of Interface.base methods for viewing
the documentation for an Interface and for querying an interface. So the
Interface/Component mechanism is intended to be a method of documentation,
along with a query mechanism that ties the documentation to the component
class. It seems like it's a way of adding some discipline to the process of
documenting the contract for a component. But if one were disciplined enough
to document through some other mechanism -- like a plain old API doc -- the
Interface thing would be superfluous.

Have I understood this whole thing correctly, or am I missing something?

By the way, I am aware that the question of whether and to what extent an
abstraction mechanism (such as abstract classes in C++) would be useful in
Python has already been discussed on comp.lang.python (see for example:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=82ads7q9u5.fsf%40
acropolis.localdomain&rnum=7&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DISO-8859-
1%26q%3Dpurpose%2Bof%2Binterface%2Bclass%2Bgroup%253Acomp.lang.python.*%26bt
nG%3DGoogle%2BSearch). I certainly do not mean to cause a flame war about
this question here. I'm just trying to understand what the Interface module
is for.

Many thanks!

--Phil







Philip Glaser
Principal and Software Architect
Sustainable Software Solutions, LLC
StillSmallVoice@DirectvInternet.com
www.sustainsoft.com
973-951-9522