(part of ZopeInAnger)
Forget those explanations about patterns. And forget about Python classes.
Interfaces are a Zope 3 invention mainly to:
- Allow the exposing of an API (every component has an external interface)
- Allow the Zope 3 machinery to query the interface
Interfaces can be queried by Zope 3 so when they are registered factories can find them.
Interfaces can be queried by Zope 3 so they can be used to automatically add documentation through the [ZMI]?.
Interfaces can be queried by Zope 3 so definitions allows so called schema's - basically a list of fields - to be queried and webforms to be automatically generated.
Interfaces can set constraints - so when you access a value they can throw an error allowing for strict(er) type checking.
Interfaces can set constraints - so, for example, containers know what other interfaces can be contained.
Interfaces need to be declared as implemented within your Class definitions - thereby allowing Zope 3 to query for an instance of an object that provides that interface.
Key to understanding interfaces is that they can be queried and constraints can be added. Quite simple, really.
Python is a dynamically typed language and class definitions are not protected. By introducing interfaces a promise is made by any Class that declares that it implements a given interface to actually implement that interface. Python being a dynamic language, it is possible to implement only part or even none of an interface and still declare that an interface is provided by that Class. Sometimes this is done as a convenience in the prototyping phase of development, but feature complete code should always implement the full interface as declared. Any Zope 3 developer who is providing a baseline guarantee of quality for their code will always implement the full interface that they are declaring, as well as provide a level of assurance that the implementation is correct through automated testing suites.
In fact the interface solution is quite elegant. Because - by virtue of a shortcoming in Python, one could argue - Zope 3 now has a standard convention for components to expose their interfaces.
Other computer languages have the option of stricter class definitions - but many frameworks would actually benefit from such an interface specification.
I hope this helps you understand Zope 3 interfaces. To study how to implement them see ZopeGuideInterfaces.
If you feel this page can be improved please edit it. Note: I make it a point not to get too technical - that is left to the (online) books.
The Interfaces wiki contains the history of zope.interface development, as well as some more recent discussion.
The zope.interface.README.txt file provides a complete discussion and set of examples for working with interfaces. The information below is from the doc string from zope.interface.interfaces.IInterface? and provides a good, succinct description of what a Zope 3 Interface object is.
Interface objects Interface objects describe the behavior of an object by containing useful information about the object. This information includes: o Prose documentation about the object. In Python terms, this is called the "doc string" of the interface. In this element, you describe how the object works in prose language and any other useful information about the object. o Descriptions of attributes. Attribute descriptions include the name of the attribute and prose documentation describing the attributes usage. o Descriptions of methods. Method descriptions can include: - Prose "doc string" documentation about the method and its usage. - A description of the methods arguments; how many arguments are expected, optional arguments and their default values, the position or arguments in the signature, whether the method accepts arbitrary arguments and whether the method accepts arbitrary keyword arguments. o Optional tagged data. Interface objects (and their attributes and methods) can have optional, application specific tagged data associated with them. Examples uses for this are examples, security assertions, pre/post conditions, and other possible information you may want to associate with an Interface or its attributes. Not all of this information is mandatory. For example, you may only want the methods of your interface to have prose documentation and not describe the arguments of the method in exact detail. Interface objects are flexible and let you give or take any of these components. Interfaces are created with the Python class statement using either Interface.Interface or another interface, as in:: from zope.interface import Interface class IMyInterface(Interface): '''Interface documentation''' def meth(arg1, arg2): '''Documentation for meth''' # Note that there is no self argument class IMySubInterface(IMyInterface): '''Interface documentation''' def meth2(): '''Documentation for meth2''' You use interfaces in two ways: o You assert that your object implement the interfaces. There are several ways that you can assert that an object implements an interface: 1. Call zope.interface.implements in your class definition. 2. Call zope.interfaces.directlyProvides on your object. 3. Call 'zope.interface.classImplements' to assert that instances of a class implement an interface. For example:: from zope.interface import classImplements classImplements(some_class, some_interface) This approach is useful when it is not an option to modify the class source. Note that this doesn't affect what the class itself implements, but only what its instances implement. o You query interface meta-data. See the IInterface methods and attributes for details.