[PEAK] PEAK Components: beginner questions

[Duncan McGreggor]

On Sep 22, 2004, at 12:34 AM, Phillip J. Eby wrote:

>> Usage clarification: IPhysiology would only be used in software 
>> agents simulating living entities; with them, there would be no 
>> implementation of IBody. However, a manufacturing robot (e.g., one 
>> you would find in an assembly line) simulation would implement IBody 
>> (and obviously not IPhysiology).
>
> Then clearly there isn't an inheritance relationship.  Inheritance 
> should follow the Liskov Substitution principle: the subclass may be 
> used wherever the superclass is called for.
>
> Specifically, your "software agents with no IBody" could not be used 
> where an IBody was called for, could they?  That means that 
> IPhysiology *isn't* a body.
>
> Inheritance is an "is-a" relationship.  Is a physiology a body?  Heck 
> if I know, I find your example interfaces and methods sufficiently 
> weird that I have no intuition about whether that makes any sense.  
> But going off of what you say here, I would say that this is *not* an 
> inheritance relationship.  And, if I go off the (normal English) 
> meaning of the words "body" and "physiology", I might think that a 
> body was a physiology, or that a body has a physiology, but I 
> absolutely would not think that a physiology is a body!  (And 
> therefore, wouldn't expect to see IPhyisology derive from IBody.)
>
> A general word also about interface design: interfaces are about 
> behavior, and you should question any interface whose name is a noun 
> that doesn't imply behavior.  I don't know what a physiology or a body 
> is supposed to *do* from just those names.  Contrast with interface 
> names in PEAK: adjectives such as 'IAttachable', 'IConfigurable', and 
> even the nouns tend towards action descriptions: 'IResolver', 
> 'IObjectFactory'.

This is good information. I was only introduced to interfaces this year 
(one of the boys at ZC), and expect I will be learning their subtleties 
for a while. However, most of the professional coders I know never use 
interfaces in their work (they are in Bruce Eckel's "salesable" and 
"it's just a job" categories). The ones that do use it have a little 
more experience than me, but they view interfaces in the same way I 
did: "just take any class, strip out the code, leave the method sigs 
and doc strings, and you've got your interface."

So not only do we not really see how they should be designed, we don't 
even look at them from the right end: we tend to "write" our classes 
first, and then the interfaces. Your comments about behavior put a 
fresh perspective on things... it makes interfaces a vital part of code 
as opposed to a only being a docstring container.

Thinking about behavior then: perhaps IMovable instead of IBody, and 
then methods that define an ability to move, and checks for hinderances 
to such mobility? As far as the physiological checks one would need to 
do on a "human" agent, I will need to give that much more thought.

> But I digress.  The point is, an interface usually is -- or should be 
> -- 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.
>
> 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.

Very, very helpful. This is in my "coding standards" wiki notes now.