CSC223 2004F, Class 5: Polymorphism (3): Factories

Admin:
* Questions on the homework (due this Friday)?
  * Write a short, interesting, program that takes advantage of the factory idea.
* New short homework: Read chapters 3, 5, and 6 of Fowler.
  * If you haven't read chapters 1 and 2 of Fowler, read them, too.
* Apologies for moderately prepared class.
* .txt files are linked from .java files.

Overview:
* Factories, Reviewed
* Anonymous Inner Classes
* Factories, Re-reviewed

/Factories/

* An interface you can use to make classes.
* See the gumball machine factory example.
* Generally: Interface specifies a makeXXX method, individual implemenations give different implementations of makeXXX.
* Good useful design patterns apply in many situations.

/Anonymous Inner Classes/

* Java-ism that works well with factories.
* Inner: Place classes inside of other classes.
* Anonymous: You don't need to name these classes.
* Useful if you need only one instance of the class (in fact, it's difficult to have more than one instance of such a class)
* Factories usually don't need more than one instance.
* Syntax?
	Thing x = new Constructor(parameters) {
		overridden-methods();
	}
* Alternate syntax
	Interface x = new Interface() {
		implementations-of-methods();
	}
* In Scheme
	(sort (lambda (x y) ...) ...)
* In Java
	new BiggerCandyMachine(new CandyMachineFactory { ... }))
* Similar benefit to anonymous functions in Scheme.

/Factories, Revisited/

* Philosophy of the Design Patterns book:
  * There are certain kinds of problems that occur frequently (in different forms)
  * Find general solutions to these problems.  These solutions are "patterns"
* Lots of ways we specify a pattern
  * Intellectual foundation: Christopher Alexander
  * Abstract Factory is one such pattern
  * Intent: What does this pattern do?
  * Aliases: Kit
  * Motivating Example
  * Applicability: What kinds of problems do you use this for
  * Structure: How do the classes relate (ooh, we need pictures)
  * Participants: What are the classes?
  * Collaborations:
  * Consequences: What does this do for us?  What does this do to us?
  * Implementation
  * Examples
  * Known historical uses
  * Related patterns
* Motivating example: GUI programs
  * Need createWindow, createButton, etc.
  * But different systems have different windows, buttons, etc.
  * A factory with createWindow, createButton, etc. methods will work.
* Note: factories may create multiple objects (using a different method for each object)
* Applicability.  We use this pattern when:
  * (1) System should be independent of how a group of products are created, composed, and represented.  [We care about interface of the objects we use within our program, not their implementation.]
  * (2) System should be configured with one of multiple families of products.  [We can use GumballMachines or ChickletMachines or ...; We can use Macintosh, or Windoze, or Motif, or ...]
  * (3) A family of product objects is designed to be used together, and you need to enforce this constraint. [Lots of related objects under one "umbrella".]
* Implementation: (You've seen it.)
  * Interface specifies buildX, buildY, buildZ
  * Each family gets its own implementation of buildX, buildY, buildZ
* Consequences?
  * Might be more efficient.
  * Makes it easy to switch between "product families"
  * Promotes consistency.
  * Discourages "coding to existing classes"
  * However, makes "supporting new kinds of products" difficult

/On to UML/
* What did you learn in chapters 1 and 2 of Fowler?
* Describing the interrelationship of parts in an object oriented system
  * Is essential
  * Is potentially hard
* Code is not a good way to communicate designs
* Pictures may be a good way to communicate designs
* At least two kinds of designs:
  * Sketches of ideas along the way
  * Documenting all the intracacies of huge systems
* Fowler's focus is on sketching
* Need a common language so that the same symbol means the same thing to everybody.
* Need to make sure that the language covers all the kinds of things we'd like to talk about in our sketches (and documentation)
* Through a variety of circumstances, UML became that language: "The" common graphical modelling language for object oriented programming.
  * Static: Models relationships between objects and the structure of objects.
  * Dynamic: Model procedures/activity
* Pictures on Wednesday!