The Coad Letter: Modeling and Design Edition, Issue 50, Coad Letter Categories

By: Coad Letter Modeling Editor

Abstract: In this issue, we look at the interface or plug-in point archetype in Color Modeling.

Dear Friend,

Welcome to another issue of The Coad Letter!

Today's questions:

  • Do interface names classify classes?
  • Do interface names classify behavior?
  • Or both?
That what this issue is all about.


Acknowledgement: J Kyle Rickett <> for his timely e-messages. Thanks Kyle!

Naming Interfaces, Revisited

With more experience with interfaces in practice, we've thought more and more about what makes a good interface name. We've discovered some more things about useful interface  names along the way.

We still like using "I" as a prefix, so we readily know in any context whether we are dealing with a class name (for example, Applicant) or an interface name (IApplicant).

Let's consider what goes after that prefix.

You see, in practice, interface names give you a way to classify:

  • The kinds of classes whose objects you want to plug into that plug-in point:
          getAddress, setAddress
          getLegalName, setLegalName
          getNumber, setNumber
          addPartyRole, getPartyRole, removePartyRole

     with a "kinds of classes" interface name that follows this pattern

      I<noun, just like a class name>
  • Or the kinds of behavior you want such objects to exhibit
    ITotal (or ICalcTotal)

    with a "kinds of behavior" interface name that follows this pattern:

       I<verb, just like a method name>
Which approach is better? Or perhaps it is better to ask: which approach when?

The "kinds of classes" classification can be expressed with interfaces or with superclasses; after all, "is a kind of" is the central idea behind an effective subclass-superclass relationship. We usually take on the main problem-domain classification first, with inheritance. For other "kinds of classes" classifications, we use interface names built with a noun.

The "kinds of classes" interfaces work well for plug-in points at the end of an object connection or the end of a message-send--describing the full spectrum of interactions (more than just a "get" and a "set") along that path.

In contrast, the "kinds of behavior" interfaces work well for:

  • Little groupings of functionality within an "is a kind of" classification scheme, and
  • The functionality required at an algorithmic plug-in point

In practice, the most common "kinds of classes" names we use in object models correspond to the "pattern players" in the companion book, "Object Models: Strategies, Patterns, and Applications." As class names, we can express those pattern players this way:

Party, PartyRole
Place, PlaceRole
Thing, ThingRole
Moment, Interval
LineItem, ItemDescription, SpecificItem
Yet often we find that we want one of these categories (e.g., Role) to offer the same interface as another (e.g., Party) and so we end up using interfaces for such overlaps--and inheritance when we don't:
IParty, PartyRole
IPlace, PlaceRole
IThing, ThingRole
LineItem, IItemDescription, SpecificItem
Each of those "kinds of classes" classes and interfaces might consist of a number of little "kinds of behavior" interfaces, for example:
IParty: IAddress, IConnectPartyRole INameLegal, INumber
PartyRole: INumber, IConnectMoment
IAddress: getAddress, setAddress
IConnectMoment: addMoment, getMoment, removeMoment
IConnectPartyRole: addRole, getRole, removeRole
INameLegal: getNameLegal, setNameLegal
INumber: getNumber, setNumber
Problem-domain objects need large-grain interfaces like IParty and IPlace--and occasionally a plug-in method interface like ITax. In contrast, human-interaction objects often need fine-grained interfaces like IAddress and INumber.

Using "kinds of classes" interfaces requires that some class provide the creation services for objects of that type; such a class is known as a factory (let it know what kind of object you need and it makes one up for you).

Server Response from: ETNASC04