SE450: Lecture 9 (More Patterns)

Announcements

Iterator

Adapter

Proxy

Decorator

Remaining schedule

Quiz next week

• ~1 hour
• Closed book/Closed notes
• Covers primarily 2nd half of class (patterns)

Sign ups for final presentations (next slide for times)

Sign up for three 20 minute choices for your presentation, in order of preference. You will receive the spot if you are the only person requesting that spot. If others have requested that spot and you have a higher rank, you will receive the spot. Ties result in a random drawing between students bidding for the same slot.

Available Slots (20 students/26 slots):

Monday, March 17th (13 slots):

• 5:40 PM
• 6:00 PM
• 6:20 PM
• 6:40 PM
• 7:00 PM
• 7:20 PM
• 7:40 PM
• 8:00 PM
• 8:20 PM
• 8:40 PM
• 9:00 PM
• 9:20 PM
• 9:40 PM

Tuesday, March 18th (13 slots):

• 5:40 PM
• 6:00 PM
• 6:20 PM
• 6:40 PM
• 7:00 PM
• 7:20 PM
• 7:40 PM
• 8:00 PM
• 8:20 PM
• 8:40 PM
• 9:00 PM
• 9:20 PM
• 9:40 PM

You are encouraged to use a laptop if you have one, otherwise, you will need to demonstrate your code on one of the lap computers. Please have redundant sources for your project (2 disks, or a disk and an email) so that you don't have to reschedule. Arrive 15-20 minutes early to start setting up your project on the other computer so that you will be ready to go when your time begins.

I will supply you with a sheet showing the 20 minute schedule in a little more detail the week of the presentation.

• Name - Iterator
• A.K.A - Cursor
• Intent - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation
• Problem -
  • An aggregate object like a list needs to be accessed, but you don't want clients to see (or depend on) the implementation of the collection.
  • You might have multiple ways to traverse a collection, and you don't want to bloat the collection interface with all the methods to navigate it.
  • We want to write generic code to traverse multiple types of aggregate objects
• Solution - Create an iterator interface that knows the internal structure of the aggregate object and can traverse it according to the interface that it defines.
• Participants and Collaborators
  • Iterator
  • ConcreteIterator
  • Aggregate
  • ConcreteAggregate
• Consequences
  • It supports variations in the traversal of an aggregate
  • Iterators simplify the Aggregate interface
  • More than one traversal can be pending on an aggregate
• Implementation
  • Who controls the iteration? - client - external iteration, iterator - internal iteration.
  • Who defines the traversal algorithm? - it can be controlled by the client as well
  • How robust is the iterator? - what if the aggregate changes?
  • Additional Iterator operations - can supply method for more direct and quick access
  • Iterators may have privileged access - Iterators can be inner classes in Java
  • Iterators for composites - may usually be internal iterators
  • Null iterators - makes travelling a composite easier - it is always done.
• GoF Reference (257)
• JDK implementation:
  In JDK 1.1 and below:

  public interface Enumeration {
    public Object hasMoreElements();
    public Object nextElement();
  }
  

  In JDK 1.2 and above:

  public interface Iterator {
    public boolean hasNext();
    public Object next();
    public void remove();
  }
  

Example files are here

• Name - Adapter
• A.K.A - Wrapper
• Intent - Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
• Problem -
  • A class that is designed for reuse isn't reusable because the interface it implments doesn't match the inteface of the problem domain.
• Solution - Class Adapter: Inherit the interface of the Target and the Adaptee (if possible, not likely in Java), or Object Adapter inherit the interface of the Target, and compose the Adaptee, calling the method of the Adaptee as appropriate using the Target interface.
• Participants and Collaborators
  • Target
  • Client
  • Adaptee
  • Adapter
• Consequences
  • A class adapter is usually a little less flexible, since it is extending a class instead of implementing a common interface.
  • An interface layer between Adapter and Adaptees can be added to make them more flexible.
  • The adapter can be part of the calling framework, allowing the adapter to be customized for its use instead of having the adaptee be concerned about adapters.
  • The adapter may need to introduce or transform parameters as part of its work.
• Implementation
• GoF Reference (139)

Example files are here

• Name - Proxy
• A.K.A - Surrogate
• Intent - Provide a surrogate or placeholder for another object to control access to it.
• Problem -
  • Remote Proxy - You want to provide access to a remote object
  • Virtual Proxy - You want to create expensive objects on demand (lazy loading)
  • Protection Proxy - You want to control access to an object.
  • Smart Reference - You want to provide a replacement for a bare pointer (not needed in Java, but is applicable for providing a way to unload resources that aren't freed by the garbage collector)
• Solution -
• Participants and Collaborators
  • Proxy
  • Subject
  • RealSubject
• Consequences
  • A remote proxy may hide the fact that an object is in a different address space (performance issues, etc)
  • A virtual proxy allows optimizations for object creation
  • Protection proxies and smart references allow additional housekeeping to take place when an object is accessed.
• Implementation
  • Proxies don't have to know the real subject if they can deal with an interface.
• GoF Reference (207)

Example files are here

• Name - Decorator
• A.K.A - Wrapper
• Intent - Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
• Problem -
  • You want to add responsibilities to individual objects dynamically and transparently without affecting other objects
  • You want to create responsibilities that can be withdrawn
  • When you want to alter behavior of a set of classes and extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing.
• Solution -
• Participants and Collaborators
  • Component
  • ConcrecteComponent
  • Decorator
  • ConcreteDecorator
• Consequences
  • More flexibility than static inheritance
  • Avoids feature-laden classes high up in the hierarchy
  • A decorator and its component aren't identical
  • Lots of little objects - can be difficult to debug
• Implementation
  • Interface conformance - the decorators need a common interface
  • Omitting the abstract Decorator class - if adding only a few Decorators
  • Keeping Component classes lightweight - the subclasses should contain the guts, not the superclass
  • Changing the skin of an object versus changing its guts - this is a Decorator vs. Strategy issue.
• GoF Reference (175)

Example files are here

Revised: 2003/3/3