Lecture 12 Part 2: Factories and Superclasses as Service Providers

Ambient temperature: 73.2oF

Concepts

  1. Systems with prototypes do not care where the prototypes come from, so long as they have one. Have a “IPrototypeShapeFactory” hierarchy that can produce the prototype (size ~ 1.0 units) of any kind of shape, when you need it.
  2. Polygon and Image factories cannot store a unit-sized prototype; they will instead store whatever size is available. When asked for a prototype, they will apply a transformation to create a reduced-size version that is unit-sized, then return that new version instead of their “internal” prototype.
  3. The Decorator Design Pattern allows you to extend or customize the behavior of one instance of an Object, versus the entire class of Objects. If you wanted exactly one specific ball to always be a color that the user chooses, for example, but didn’t want to write “AlwaysRedStrategy, AlwaysBlueStrategy, AlwaysGreenStrategy…” implementations, you could create a Decorator class that wraps a Strategy instance, and forces that one instance to always paint a particular way.
  4. The Template Design Pattern features an Interface, implemented by an Abstract Class. That Abstract Class implements the default behavior of each of the Interface’s methods. Wherever possible, it breaks this default behavior up into a series of other method calls in the Abstract Class (NOT in the interface). These methods are an example of “extensibility hooks.” To customize the behavior of a sublcass, programmers then override just the hook methods that deal with the behavior they want to modify. For example, instead of overriding and completely re-implementing paint(Graphics _g) { … } just to change the color, a Template-based Abstract Class might define the protected abstract void prepare_color(Graphics _g, IUpdateContext _c) method, which you would override instead. That way, you do not have to re-write code for painting, transforming, or any other behavior. This is another way of “separating the variant from the invariant.”
  5. Variable Input Argument Lists were introduced.
    1. The JVM does not implement them; they are compile-time syntactic sugar, therefore
    2. Java Reflection does not (and can not) support calling vararg methods.
    3. You cannot pass a single object that is an array.
    4. They are a convenience feature only; no new capabilities are granted, so
    5. Just don’t use them.

Resources

  1. Lecture 12 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec12/
  2. Lecture 13 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec13/