[Zope3-dev] defining interfaces

Steve Alexander steve@cat-box.net
Sat, 05 Apr 2003 14:47:29 +0200


Garrett Smith wrote:
> There appears to be several ways in which interfaces are defined in the
> Zope3 package. What is the recommended approach for people creating
> simple products and/or complex frameworks?

To explain this, we need a the concept of a Project as some cohesive 
piece of software implementation.


A project might take the form of

* A single python module (a .py file)

* A single python package (a directory containing an __init__.py file)
   that contains various modules.

* A python package that contains other modules and packages.


A Project might have no interfaces, or it might have a few interfaces, 
or it might have a whole bunch of interfaces. If a project has no 
interfaces, we have no problem of where to put them.

When a project is a single python module, then the interfaces should
go in that module, preferably at the start.

When a project is a package, if it has just a few interfaces, they 
should go in a module called 'interfaces.py'.

When a project is a package, and it has lots of interfaces, they should
be arranged in modules under a package called 'interfaces', where the 
arrangement of interface modules and packages mirrors the arrangement of 
the modules and packages that provide implementation for the project.


Here's an example:

Let's say I have /home/stuff on my PYTHONPATH.  My company is called 
"FooCorp", so to avoid namespace conflicts, I'll put all my projects 
inside a 'foocorp' package.

/home/stuff                      directory on the PYTHONPATH
/home/stuff/__init__.py          makes /home/stuff into a package
/home/stuff/foocorp              directory to contain my projects
/home/stuff/foocorp/__init__.py  makes /home/stuff/foocorp a package

A very small project called 'Bar Toolkit' might all live in a module 
called 'bartools.py'. The interfaces would live in that module.

/home/stuff/foocorp/bartools.py  interfaces and implementation of bar
                                  toolkit

However, if I want people to provide alternative implementations for the 
software in the 'Bar Toolkit', I'll want to provide the interfaces 
separately. There are a few ways to do this. I might add the interfaces 
to a general 'interfaces.py' module. But, that causes problems for 
installing and updating other projects in /home/stuff/foocorp.
Instead, I might define the interfaces in 
/home/stuff/foocorp/interfaces/bartools.py.

/home/stuff/foocorp/interfaces   package for foocorp interfaces that
                                  aren't in their own project package
/home/stuff/foocorp/interfaces/__init__.py
                                  makes /home/stuff/foocorp/interfaces a
                                  package
/home/stuff/foocorp/interfaces/bartools.py
                                  interface declarartions for bartools.


I could instead choose to make the interfaces available in a separate 
module at the same level as bartools.py, and call this module 
ibartools.py. However, this approach is discouraged.

/home/stuff/foocorp/ibartools.py  alternative location for bartools
                                   interfaces


Let's talk about a larger project, "Baz Toolkit". This consists of 
several modules in a package for implementation, and five or six 
interfaces collected into one file.

/home/stuff/foocorp/baztools     directory for baz toolkit
/home/stuff/foocorp/baztools/__init__.py
                                  file to make directory into a package
                                  that might contain some implementation
/home/stuff/foocorp/baztools/system.py
                                  some more implementation for baztools
/home/stuff/foocorp/baztools/browser.py
                                  browser views provided for baztools
/home/stuff/foocorp/baztools/adapters.py
                                  perhaps adapters can go here, if there
                                  are a bunch of them that don't fit
                                  elsewhere
/home/stuff/foocorp/baztools/interfaces.py
                                  all the interfaces for the baztoolkit


Let's say I have a much larger project, "Spoo Toolkit". This consists of 
many subpackages of a main package. Each subpackage has its own 
interfaces. I also want to split off the browser views from the main 
implementation. So, I have three trees: Main implementation, Browser 
views, Interfaces.

/home/stuff/foocorp/spootools    directory for spoo toolkit
/home/stuff/foocorp/spootools/__init__.py
                                  makes this a python package.
                                  might contain implementation,
                                  but may well not do, if we want to
                                  consider spootools just a
                                  'namespace-only package'.
/home/stuff/foocorp/spootools/systema.py
/home/stuff/foocorp/spootools/systemb.py
                                  implementation in modules
/home/stuff/foocorp/spootools/systemc
                                  directory for subsystem c
/home/stuff/foocorp/spootools/systemc/__init__.py
                                  make directory a package
                                  contains some implementation
/home/stuff/foocorp/spootools/systemc/subsysx.py
                                  subsystemx of systemc
/home/stuff/foocorp/spootools/interfaces
                                  directory for interfaces
/home/stuff/foocorp/spootools/interfaces/__init__.py
                                  make directory a package
                                  contains important interfaces
                                  used in systema and systemb
/home/stuff/foocorp/spootools/interfaces/systemc.py
                                  contains interfaces for systemc
                                  and subsystemx
/home/stuff/foocorp/spootools/browser
                                  contains browser views
                                  fill in the __init__.py and other
                                  modules and directories as you need!

--
Steve Alexander