CSC323 2010S, Class 25: Design Patterns (3): Structual Patterns

Overview:
* Structural Patterns
* Basic wrapper patterns
* Group wrapper patterns
* Other wrapper patterns
* Other structural patterns
* Project fun

Admin:
* EC for Convo on Thursday.
* EC for CS Table on Friday.
* Parser
* T-shirt idea:  Sheep on front w/ "Why is there a sheep on the CS
  T-shirt"  Back: "It's a lamb, DUH."  
* No reading for Thursday!
* Bring:
  * Short status reports.
  * Goals for class period.

What makes a pattern "Structural"
* Describes structures/relationships among objects
* Describes how classes and objects are combined to form larger 
  structures.
* In contrast, creational and behavioral speak more about interaction.
  * But structural have some interaction and c/b have some structure.

Most of the structural patterns involve "wrapping" an existing class
to alter its functionality in some way.
* Hence, it can be hard to distinguish these patterns, since "wrap"
  is the basic operation

Basic Wrapper Patterns
* Adapter
* Bridge
* The Adapter pattern
  * Start with a similar but not quite matching need and capability
    * Need in one class
    * Capability in another class
  * The adapter links the two
    * It provides the needed capabilities using the provided capabilities
  * Example: Stored as integers, Client needs T/F.  Adapter translates
    from one to the other.
  * Example: Have Array.  Need List.  
  * Two techniques for adapting (Class Pattern or Object Pattern)
  * How might we decide which one to use?
    * Memory usage
    * Resiliance to change
    * Proliferation of classes
    * Repetition of code
    * Generality / Generalizability
* Bridge: Handling independent changes

Group Wrappers: Take lots of objects and put them together into a single "thing"
* Composite
* Facade
* Composite: Allows a group of objects to be treated in the same way
  as a single element of the objects.
  * Example: Predicate
    * The And object has the same methods as the things we And together
  * Composites let us build nice hierarchical structures at run time.
  * Why does the composite object (e.g., And) aggregate its stuff rather
    than associate?
    * To enforce tree-like structures
  * Note: While the standard pattern permits the composite objects to add
    and lose children, Sam believes in building non-mutable structures.
* Facade: Provides a simpler interface for a large and complex group
  of objects.
  * Instead of dealing with the individual objects, clients deal only
    with the front-end object.
  * E.g., a manager with a department
  * E.g., a computer does "X" rather than "the memory does A and the CPU
    does B and the keyboard does "C"
  * Why is this a good model?
    * Conceals complexity: Client only deals with simplified model
    * Makes it easier to change underlying archicture
  * Why might this be a less good model?
    * Conceals features: You can no longer tweak the individual
      components.
  * Improving?: You can also give the client access to the internals
  * How might we use Facade in our project?
    * One might argue that any compound class is a facade, so Network
    * We could treat World is more of a facade

Other wrapper patterns
* Decorator
* Proxy
* Decorator: Wrap a class and provide the same interface as the
  wrapped class.
  * Add functionality to wrapped class
* Proxy: Wrap a class and provide the same interface as the 
  wrapped class.
  * Purpose: To delay or simplify the operation of the wrapped class.
* Decorator:
  * Example: Readers in Java
  * Example: Debugging/Logging wrappers
    void quux()
      printf("quux()")
      this.stuff.quux()
    Simple change in program to get debugging.  
    From
      this.stuff = new Foo()
    to
      this.stuff = new DebuggableFoo(new Foo())
  * Example: Profiling
  * Benefits:
    * Easy to add functionality: Just wrap
    * Why decorators rather than inheritance (easy to add functionality,
      just inherit, override, and call parent methods)
    * Allow combinations (e.g., wrap1 wrap2 wrap3 (original)) w/o
      exponential blowup in number of classes.
  * Potential Dangers? (vs. inheritance)
    * Inheritance may be simpler
    * Requires us to implement many methods, not all of which are
      decorated
      * Can be solved by better language design
* Proxy: Provide an interface to more complex objects
  * Virtual proxy: Delay the construction of "expensive" objects. 
  * Remote proxy: Store the object elsewhere on the network.
  * Protection proxy: Check for permissions (or is this a Decoration?)
  * Why to use: When you may need a heavyweight object, but parts of
    its use can be delayed.

The Last Main Structural pattern
* The Flyweight

---- 

Project stuff:
* The Model Group
  * Can not read species from files.  On "to do list"
  * Has not had a chance to do much work yet
* The GUI Group
  * Draw a board that says "Hi Jordan".  DONE.
  * Made it more efficient.  Instead of drawing a button for each cell,
    they draw colored rectangles.
  * Pays attention to clicks.
  * Do it with Menu.run()
  * Started working on it as a listener.
  * Goals for Thursday:
    * Talking to LocalWorld.
    * Convince the Model Group to build a species database.
      * Including a Conway species.
* The Network Group
  * Still figuring out what they're doing.
  * Trouble transmitting Enums.  Now works.  But not committed to it working.
  * Lots of testing.
  * Now can import from model folder.
  * Goal for Thursday: 
    * More tests.
    * Server needs to accept clients.  (More reimplementation.)
    * Pass lists of instructions between servers and clients.
  * Needs from other groups
    * A decent collection of species.

Cool idea: Class period to work on the project.  THURSDAY!

Obsevation:
* LOC is becoming a harder and harder thing
* Lots of time in intra-group communication
  * But Sam thinks it results in learning
* Conficting desires
  * "I want to be a specialist"
  * "I want to be a generalist"
  * We've supported the generalists