Some rules for class design:

  * A class should be focused ("coherent")
  	A class should be about one thing
  * Class operations should be consistent
    both syntactically and semantically
    a bad example: date_op1(month,day), date_op2(day,month)
    don't use set_day and then mutator week()
  * A class should provide a complete set of operations
    Should allow most (relevant!) things
    But note two Rectangle classes, doing different things.
    Also note that a Stack class *should* lack, say, get_nth()
  * class types are the norm; reconsider long member lists of primitive types
    example: fname, mi, lname, streetaddr, city, state, zip
    Better: name, addr fields, where these are made up of primitives
  * primitive operations are better in *many* cases
      bool List::advance(int & value): too compounded
    versus:
	bool List::atend();	// these are each primitive
	void List::advance();
	int List::getcurrent();
  * sometimes break these rules for convenience


Some class patterns
  * tangible things, eg Document, Font, Stock_Item, Picture
  * System interfaces; eg an I/O wrapper
  * Events (eg MouseEvent)
  * Transactions
  * Network connections (sort of like I/O above)
  * Users (both by "name" and by "role")
  * main system driver
  * Containers: there is almost always a type parameter issue
  * Primitive classes: Integer, String, Vector, Date, etc
  


Some warning signs:
Reconsider your design when:
   * your class has too many members
   * your class has some operations unrelated to others
   * your class is related to too many other classes 
     (except for "main", system-driver classes)
   *