🚀 go-pugleaf

: >2) Which brings me to "interfaces" which don't make sense to me either.
: >What is the major difference
: >between an "interface" and a "superclass"? 
: >The book says the advantage is that you can define the protocols for an
: >abstract class without worrying
: >about the specific implementation, leaving that until later. WHY?  

: An abstract  superclass usually exists to _define_ an interface, an
: interface being the collection of public methods associated with a
: class.  Grady Booch defines an interface as "The outside view of a
: class, object or module, which emphasizes its abstraction while hiding
: its structure and the secrets of its behavior."  ("Object-Otiented
: Analysis and Design with Applications" 2d edition ISBN 0-8053-5340-2,
: pg.515)

: You might want to read the first four chapters of that book.  Another
: very useful book is "Designing Object-Oriented Software" by Rebecca
: Wirfs-Brock, Brian Wilkerson and Lauren Wiener (ISBN 0-13-629825-7)
: which has a good discussion of abstract classes starting on page 27.

in fact, interfaces are an essential principle behind corba (and idl)
and ole (and com). it is for that very reason that jim and I decided
to reify the concept of an interface in our unified method.
specifically, we treat an interface as a first class citizen,
permitting one to manage and control protocols. this is particularly
useful if you use interfaces to control an architecture, or
to separate type and class lattices, or to permit mutiple implementations
of the same interface (as is found in distributed systems).

I describe how we do this in the january 96 issue of road, in
an article about properties and stereotypes