Let's pretend that you've finished the OOA, so you have a
  model, and the OOD can be done in isolation.  This isn't
  necessarily so, or even desirable in many circumstances.
  We'll concentrate on what happens during OOD, though, but bear
  in mind that sometimes you break off and go back to OOA for a
  while to straighten something out.
  
  In OOD you're trying to design the structure of each class,
  and what the class hierarchies are.
  
  Start with collaborators.
  
  Composition is where a class is a part of another class.  In
  English, this may be expressed as: first thing has a second
  thing.  For example, a car has a steering wheel, which can
  also be expressed as: the wheel is part of the car.  You
  implement composition by having instance variables that store
  other objects.
  
  You have to decide whether other classes should be aware that
  a particular class is a composite class.  In general, it's
  better not to make them aware because you're probably breaking
  encapsulation.  You may be making changes harder to do, and
  limiting re-use.
  
  When a class uses another, this is a client/server
  relationship.  A class which knows about another or gets
  something from another also indicates a client/server
  relationship.  Both client and server are classes.
  
  A class may delegate behaviour to a another class, normally a
  part of the class.
  
  When a class is like another, but simpler or more general-
  purpose, it is typically an ancestor of the other.  The
  opposite, a dsecendant, is where a class is a kind of another
  class.  The more specialised class nearly always inherits from
  the more general class.
  
  Once you have designed enough classes you can start checking
  their interactions and behaviours in detail to make sure all's
  still well.
  
  Incidentally, you've seen in the examples that method
  MenuSetup() uses commands to create its menus, and you may
  recall a comment to the effect that these commands make use of
  menu classes.  If you examine the files involved, you'll find
  that the #commands in MENU.CH produce calls to functions in
  MENUFN.PRG, which finally gets on with using the classes.
  
  The classes involved are WMenuBase, WMenu, WPopup, WSystemMenu
  and WMenuItem.  Despite some interesting behaviour and
  limitations imposed by Windows, it seemed clear that WMenu,
  WPopup and WSystemMenu are kinds of menu, and should therefore
  be part of an inheritance hierarchy (in this case with
  WMenuBase as the common ancestor).  Menu items are not menus,
  so they don't belong in the menu class tree, which is why
  WMenuItem is a separate class.  Any of the other classes can
  have menu items, which are stored in the aItems instance
  variable.  Being common to the menus, aItems was put in
  WMenuBase for the others to inherit.