CSC223 2004F, Class 33: More heuristic decisions

Admin:
* Real whiteboard today.  Volunteers for eboard?
* Homework due Monday: Working combined projects

Overview:
* Questions and answers
* More Riel decisions on choosing relationships
* Our own decisions on choosing relationships
* Riel decisions on choosing how to obtain objects to use
* Our own decisions on choosing how to obtain objects to use

Notes mostly written by M. Louisa Poythress.

Notes - 11/17/04 - CS223

Monday's Homework: (extended from Friday)
	Project (new teams)
	- Incorporate World, thing that builds bugs and reads bugs, and the display of the world
	- For example: (build 100 x 100 grid, read bug instructions, build bugs, build food, put in World, every second or so update the World, have bugs move around and show it on the screen - OR - everytime the user clicks, update the World (and the bugs then update))
	
Group changes:
- Beetle group is now Gene, Ryan, Jesse.
- Caterpillar group is now Luis, Evan, Omondi.

Topics:
Terminology questions
Riel on selecting relationships
CS223 on selecting relationships
Riel on choosing how to get objects to use
CS223 on choosing how to get objects to use

SAM HATES IT WHEN EVAN, SAM, AND KAT DON'T SHOW UP.  (Evan and Sam showed up late.  Kat is still missing.  Kat's friends promise to contact her.)

4 Main Relationships:
Use
Association - "creation", "containment"*, and "other"
Containment - "pure" or "by association"*
Inheritance

*are the same (almost like mulitple inheritance)

Goal: Find heuristics that tell us what relationships to use between classes.

Riel's Guidelines:
5.18: Do not confuse optional containment with the need for inheritance.
	Optional containment is when some components may not be necessary.
	(e.g. a shrimp coctail may or may not include sauce, but will still be
		a shrimp coctail)
	Riel says NO to: ShrimpCoctail subclassed by both SaucyShrimpCoctail and GreenShrimpCoctail (with lettuce)
	Riel says that it will lead to a proliferation of classes.
	Instead, have a field for the components in the original class that may be null.
	(e.g. ShrimpCoctail may have a field such as boolean sauce = true/false)
	However, DO NOT USE EXPLICIT CASE ANALYSIS (If sauce == true, then a ; if sauce == true, then b)
	
	So which heuristic to follow?
		Depends on the importance of each in the current problem. It's a trade-off. Heuristics are fuzzy, like cats.

5.14: Do not model the dynamic semantics of a class through the use of an inheritance relationship.
	Don't change from type a, to type b, to type c while running.
	If there's a change in meaning, you don't have to become a different subclass of a parent class,
		you just have to change your fields.

5.9: If two or more classes only share common data (no common behavior) then that common data should be placed
	 in a class which will be contained by each sharing class. (ie "Don't use inheritance for just fields.")
	2 classes: Sorter which provides method sort(Vector v) and
		 Searcher which provides search(Vector v, Object key)
		You know that in both these cases you share the need for a Comparator c field.
		Refactoring to the extreme: Subclassing both of them to a new class "ComparatorUser".  Not necessary.
		Inheritance is for sharing code, not for sharing a kind of data.
		
5.15: Do not turn objects of a class into derived classes of the class (subclasses).
	Don't use inheritance when fields would suffice.
	
Overall Message: Don't be overly aggressive in using inheritance.

When to use inheritance?
	Specialization hierarchy
	Polymorphism
	NOT A COMPELLING REASON: To reduce redundancy in code of methods
		Alternatives: Associating to a 3rd class that has the redundant method and have both classes call it.
		
Detour: Template Classes
	Yes, you can use them, but they are generally used:
	(1) when you want your methods to work only on specialized kinds of data
	(2) to support heterogeneous homogeneity
		Example:
		Lists can be heterogenous (contain all differents kinds of Objects)
		However, a list of Integers contains only Integers and things that subclass Integer.
End of detour.

Second Detour: Do the following two heuristics help us?
4.8: Distribute system intelligence down narrow and deep containment hierarchies.
	Call the methods in your member classes instead of having one large master class.
5.4: Theoretically, inheritance hierarchies should be deep.
	A nice specialization hierarchy.

Answer: They help us in our design, but perhaps not in our selection of what relationship to create.
End of second detour.

How to choose between other relationships?
	For next time.