WritingInterfaces |
UserPreferences |
The PEAK Developers' Center | FrontPage | RecentChanges | TitleIndex | WordIndex | SiteNavigation | HelpContents |
The following were taken from a thread where Phillip was addressing component design concepts for a beginner. Some editing was applied. For the full context, please see the links given below.
From http://www.eby-sarna.com/pipermail/peak/2004-September/001780.html :
Interfaces are behavior-oriented, and you should question any interface whose name is a noun that doesn't imply behavior (e.g., IAttachable, IConfigurable, IResolver, IObjectFactory).
An interface usually is about a single, clear responsibility. Generally speaking, you don't want to lump multiple responsibilities into an interface, because you might want to perform them using different objects at some point, and at that point you would already have a bunch of code expecting those responsibilities in one object.
Interface inheritance usually comes into play when some clients of the interface need additional capabilities, but not all suppliers of the interface will be able to provide those additional capabilities. Or, sometimes there's a component that for convenience reasons will aggregate a variety of features, and you use inheritance to assemble an interface from the various sub-interfaces.
Regarding behavior and interfaces, with interfaces being a vital part of code as opposed a docstring container:
From http://www.eby-sarna.com/pipermail/peak/2004-September/001783.html :
To some extent, this view of interfaces is influenced by ?PyProtocols/PEP 246. Without object adaptation, interfaces aren't quite as useful. But with adaptation, the best way to design a collaboration of objects is to focus on the essential and desired behaviors. Then, you determine how to adapt the behavior of existing objects to perform your desired behavior.