Click above to get retro games delivered to your door ever month!

  
  Finding the good classes tends to mean eliminating candidate
  classes, which is why you're not too concerned about having
  some extra candidates.  You should now have a collection of
  potential classes, which you need to turn into the actual
  classes; quite a few probably need to be dropped or altered.
  
  What makes a good class depends a little on your problem
  domain, but here are some guidelines.
  
  A class should represent something with well-defined
  boundaries: a specific thing.  There should be a permanence to
  it.  In other words, members of the class should remain in
  that class (as long as they exist).  Thus, a customer can be
  represented by a class, but a customer with a fax doesn't
  merit a separate class.  Having a fax or not is an attribute
  (or property), and would be handled by an instance variable.
  
  Remove or re-think any classes without well-defined
  boundaries, and any lacking permanence.
  
  Another test to apply can be a little harder to grasp.  This
  is the concept of an object's identity.  Each object of a
  class should be different in some way from other objects of
  that class, and the difference should persist for the object's
  lifetime.
  
  Going back to nuts, bolts and nails, you know that each
  individual item or object is just that: an individual.
  Similarly, for a customer class each customer is unique in
  some way or ways.  You might try to say that the uniqueness is
  the customer's name, or address, or some such attribute, but
  those could change.  The customer would not have changed,
  though, which is evidence that the customer does have an
  identity.  As a result, a customer class is justifiable.
  
  You've met these issues before in your Clipper programming, of
  course, and solved them: you allocated customer ID's, stock
  codes, etc.  So, identity isn't really anything new to you.
  Just remember to check that objects of a candidate class would
  have their own identity, which by definition must be unique.
  
  You don't need to have an instance variable to store a
  representation of an object's identity, although you can use
  one if you wish.  In the case of stock or customer objects
  you'd have a code or an ID, which would effectively fulfil the
  role of the object's identity.  However, this is just a case
  where you happen to have an explicit instance variable that
  you can use.  This is irrelevant to the OO system, as it won't
  know that you have this instance variable that's special in
  this respect.
  
  Sometimes an OO system, and especially an OODBMS, maintains an
  identity for each object.  This is nearly the case with
  Clipper / VO: you can have code like this:
  
            o1 := TBrowseNew( ... )
            o2 := TBrowseNew( ... )
  
            oTB := o1
            ? (oTB == o1)  // .T.
            ? (oTB == o2)  // .F.
  
  This works like this because assignment doesn't copy an
  object, it copies a reference (pointer) to the object.  The
  "==" (exact equal) operator is almost a test for identity, but
  fails if you can somehow make a full copy of an object.  Some
  examples of doing this would be to store it in a file (you
  need something like dBxStore or FlexFile), then re-read it
  into a different variable, or you could create a second object
  and set its instance variables from the first one.  TopClass
  even provides the TC_OClone() function.
  
  The above limitation is an implementation issue - the ability
  to copy an object doesn't alter the fact that it (logically)
  has an identity.
  
  Enough about identity - it's time to return to finding classes.
  
  Look for classes which are really the same as each other except
  for slight differences in their names/descriptions.  If you've
  described two classes using words that are synonyms, and their
  behaviour and attributes are otherwise the same, you've usually
  got just one class really.
  
  By the way, you may have to do this class elimination more
  than once, as later efforts can reveal earlier mistakes.
  
  At this point we're not done, but it's time to get more
  involved with the classes.
  
  You should start to refine the tentative model you have.
  
  Look in more detail at the interactions between your classes,
  their inputs, and their outputs.
  
  Try to identify all the behaviours and responsibilities of
  classes.
  
  Look for all the collaborations between classes, typified by
  client/server relationships.
  
  If you're using CRC cards, fill in lots of details.  If you're
  diagramming, get busy.