CSC223 2004F, Class 41: Patterns (5): Behavioral Patterns

Admin:
* Attempting to decrease their participation grade: Evan (just late), Kat, Luis, Chase, Merrick (very late)
* Donuts!
* Project due Friday.
  * Questions?
    * The specification is vague: Make it fun, Make it work, Document format of bugs, including interesting bug design
* Final essays due a week from Friday.
  * Questions?  "Approximately 2000 words" (Sam prefers APA)
* Custom evaluation due Friday.
* Standard evaluation filled out in class on Friday.
* Cool thing Saturday: Kumail the Komedian (7 pm, South Lounge)
* Participation grades distributed
* Extra credit options:
  * Chemistry Convo
  * Body Image Convo
  * Arjun Guha (Math)
  * Cassie Schmitz, Sam Martin, and Stephane Nyonbayire
  * American Studies Master Class on Incarceration
  * Davis Hart, Oge Nnadi, Dimitar Tasev
  * Liberal Arts Debate
  * Kumail Nanjiani (coming Saturday)
  * Sorting books

Overview:
* The why of behavioral patterns
* A list of patterns and their basic categories
* Questions?
* Other relationships

/Behavioral Patterns/

* Simplify method calls (message sends) by an appropriate structure
* Permit more interesting sequences of method calls (or method design)
* Attempt to simulate things the designers didn't put into the language
  * Lots of cool things from functional programming (function as first-class values)
    * Command
    * Template Method
    * Strategy
    * Visitor is something like Scheme's map
  * Like Exceptions, but different
    * Chain of responsibility
  * General good ideas from other languages
    * Iterator

/The Patterns/

Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

Functional Programming Simulations:
* Command: Treat a function as an object (adds other cool things, like undo; doesn't really let you build them on the fly)
  * Related functions do different things
* Strategy: Treat a function as an object, using interfaces (permits us to vary implementation)
  * Related functions do the same thing in different ways
* Template Method: Parameterize functions through subclassing
  * Scheme: (define sort (lambda (comparator lst) ...))
  * .... smaller(x,y) ... and subclass defines smaller
* Visitor: Apply a function at every position in a complex structure
  * Like map

Traversing Complex Structures (Collections)
* Visitor: Visit every position in a complex structure *and do something at that position* (internalizes traversal)
* Iterator: Return every value in a complex structure, one by one.  (External thing responsible for "give me the next thing in the structure") (externalizes traversal)
  * The simplest iterators provide one method: next() throws OutOfElementsException()
  try {
  	while (o = it.next()) 
		...
  }
  catch (OutOfElementsException ooee) {
  	// We expect this
  }
  catch (Exception e) {
  	// Crash and burn
  }
* Interpreter: Build and traverse a structure that depends on the input

Patterns that relate to state
* State - Encapsulate the state in a contained object, change behavior by changing the object
  * Eliminate case statements (Avoid explicit case analysis by using contained objects)
  * Not (if state==active ... else throw new Exception("foo"))
    but (state.doWhatever())
      public class Inactive implements State
        ...
	   throw new Exception("foo")
* Observer: Ask for notification of state changes
* Memento: Encapsulate state for saving and restoring (save to disk, ...)

Others (Sending Messages to a partially-known object):
* Chain of Responsibility - Provide a sequence of objects that might respond to a message
  * Gas station example: "Who will provide me with gas?"
  * Reminder: A car object needs gas, where does it get the gas from?  Illustration of "different ways to get an object to use"
  * Some languages make c-o-r implicit (LINDA)
* Mediator - Combine related objects and have them call a central mediator rather than each other
  * Like the ATM example from Riel
  * Like Facade (the book tells us so)
    * Facades group things for external calls
    * Mediators group things for "internal" calls
* Observer - I want to receive messages

Observation:
* Sometimes the "why do they have two very similar patterns" tells us more about the patterns

Questions:
* What does it mean that "behavioral patterns use object composition rather than inheritance"?  (Particularly given taht Template Method uses inheritance.)
  * Typical method of adding functionality is "include as a field" rather than "make a subclass"
  * Chain of Responsibility: Don't create a new subclass that can handle the request, include a field that lets us pass the request to another object
  * Visitor: Don't create a new subclass for "Do something to everything in this tree", pass in the "do something to a node"

* There is a claim in "Chain of Responsibility" that you can choose the chain at runtime.  Can you explain?

	public class RequestHandler
	{
		RequestHandler nextHandler;

		public void handleRequest(Request r)
		{
			if (icanhandle(r))
				handle(r)
			else if (nextHandler != null)
				nextHandler.handleRequest(r);
			else
				// Sorry, your request is lost
		}
	}

	RequestHandler default = johnDavidStone;
	default = new RequestHandler("sam rebelsky", default);
	default = new RequestHandler("evan case", default);
	// Whoops!  Evan graduated
	default = default.nextHandler;
	default = new RequestHandler("eryn o'neil", default);
	// Whoops!  Sam gives useless answers
	default.nextHandler = default.nextHandler.nextHandler;

Summary of Design Patterns:
* Encapsulate things that "professional object-oriented programmers do"
* Provide a framework that encourages careful documentation of new patterns
* Provides a language to talk about design ideas