🚀 go-pugleaf

barmar@think.com says:
                          Unfortunately, there still isn't enough
  experience in the industry in proper design and documentation of OO
  components, so you end up with code like the above.

I think it is possible to come up with some "Elements 
of CLOS Style", in the spirit of Strunk and White, that
contribute to reusable code.  It is my experience that
CLOS has more than enough tools to write simple
and general code that obeys data encapsulation.
What we need now are heuristics that provide guidance
in the selection of the right tools at the right times.

Here are a few of my personal rules which I recommend:

1.  If it can be done without extending the MOP, don't 
extend the MOP.

2.  Separate classes that provide BEHAVIOR (methods) from 
classes that provide STRUCTURE (slots).  Otherwise one
tends to implement behavior that makes too many assumptions 
about the structure of the objects involved.

3.  Avoid the use of SLOT-VALUE and WITH-SLOTS.  It is an 
indication of a missing accessor method.  

4.  Avoid the use of TYPECASE.  If you find your code
riddled with

  (typecase object
     (vehicle (vehicle-speed object))
     (frog (frog-speed object))
     (...))

Then you probably would have been better off with a
generic function called SPEED.

5.  Avoid the use of TYPEP.  Replace (typep object 'frog) with
(frog-p object) where:

(defmethod frog-p ((object t)) nil)
(defmethod frog-p ((object frog)) t)

Using a method rather than a function ensures that other
applications can extend the definition.

6.  Avoid including the name of a class in the name
of a method.  For example, rather than naming it FROG-COLOR,
just name it COLOR, since someone else will surely want to 
reuse the generic function for things other than frogs.

7.  Use &ALLOW-OTHER-KEYS in the argument list of a generic 
function if you expect to encounter argument list conflicts 
some day.

8.  Avoid writing a method that cannot fit in one screenful.

jeff morrill
jmorrill@bbn.com