SE450: Lecture 8 (More Patterns)

Announcements

More Patterns

Builder

Prototype

Visitor, Observer, Iterator

Model-View-Controller

Sign ups for final presentations will start next week

The SE450 Core exam guide is here. Look it over and let me know if there are areas you would like me to cover in more detail/review for the last class.

I'll schedule a few days at O'Hare in the next few weeks for discussing projects (and anything else related to SE450) depending on interest

• Name - Builder
• Intent - Separate the construction of a complex object from its representation so that the same construction process can create different representations. One class is responsible for building products
• Problem -
  • A class has a complicated internal structure, or order dependent setters.
  • You have too many constructors in your class to support too many possible ways to construct it.
  • The creation process uses resources or other objects that are hard to create or obtain.
• Solution - Use a Director class that is responsible for building the parts of the product using different Builders.
• Participants and Collaborators
  • Director
  • Builder
  • ConcreteBuilder
  • Product
• Consequences
  • The Builder can coordinate order constrained creation, providing fallbacks when necessary
  • The Builder can be a central point for resources needed during creation (like database connections, files, etc). This makes life much easier for clients of the Builder.
  • Many times, builders are used to build composites
• GoF Reference (97)
• Example files are here

• Name -
• Intent - Specify the kinds of objects to create using a prototypical instance, and create new objects by copying the prototype
• Problem -
  • Classes are instantiated or specified at run time by dynamic loading
  • You want to avoid building a class heirarchy of factories that parallel the class heirarchy of products
  • When instances of a class can only have a few combinations of state.
• Solution - Create a prototypical instance, and copy it (or clone it) when you need new objects
• Participants and Collaborators
  • Prototype
  • ConcretePrototype (or just a Prototype)
  • Client
• Consequences
  • Hides the concrete product class - clients don't need to change as much
  • Need to be concerned about shallow vs. deep copy
  • Allows you to return the type you want, instead of Object like the clone method of Java
• Implementation
  • Use a prototype manager
  • Implement the "clone" operation
  • Initialize the "clone"
• GoF Reference (117)
• Example files are here

• Name - Visitor
• Intent - To define a set of actions in a maintainable way that can be taken against a family of classes. Visitor lets you define a new operation without changing the classes of the elements on which it operates. The Visitor will act on data in other classes.
• Problem -
  • an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes
  • several non-trivial actions need to be taken against this group of classes.
  • The actions to be taken change depending on the classes that they are being taken against.
  • The classes defining the object structure rarely change, so removing the operation from the objects is not as dangerous.
• Solution - Define a set of actions using two class heirarchies, one for the elements being operated on, and one for the visitors that define the operations on the elements. New operations are defined by adding a new subclass to visitory class heirarchy.
• Participants and Collaborators
  • Visitor
  • ConcreteVisitor
  • Element
  • ConcreteElement
  • ObjectStructure
• Consequences
  • Visitor makes adding new operations easy
  • A visitor gathers related operations and separates unrelated ones
  • Adding new ConcreteElement classes is hard - Visitor is not a good idea if you will be adding many new classes to your program
  • Visiting across class hierarchies
  • Accumulating state
  • Breaking encapsulation
• Implementation
  • Double dispatch - the operation that gets executed depends on the types of both the Visitor and the Element. Double dispatching lets visitors request different operations on each class of element.
  • Can use an Iterator to traverse the objects.
• GoF Reference (331)
• Example files are here

• Name - Observer
• A.K.A - Dependents, Publish-Subscribe
• Intent - Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically
• Problem -
  • You have multiple aspects that you want to encapsulate in separate objects, allowing you to vary them indepedently, but you want them to be aware of each other.
  • When one object changing requires a change in another, and you don't want to force a relationship of one-to-one (or enforce any size on the relationship)
  • You want loosely coupled objects that can notify each other of changes.
• Solution - define a relationship between the observer and the subject such that an observer can obtain information about the subject, and the observer can register itself with the subject to be notified of changes.
• Participants and Collaborators
  • Subject
  • Observer
  • ConcreteSubject
  • ConcreteObserver
• Consequences
  • Abstract coupling between Subject and Observer - Subject knows very little about observers
  • Support for broadcast communication - all registrants get information
  • Unexpected updates - notification could be a big deal
• Implementation
  • Mapping subjects to their observers
  • Observing more than one subject - subject may need to identify themselves.
  • Who triggers the update? - when should the subject notify?
  • Dangling references to deleted subjects - not as big of a deal in Java, but still must be considered.
  • Making sure Subject state is self-consistent before notification
  • Avoiding observer-specific update protocols: the push and pull models - push all, or let observer pull out what they only need
  • Specifying modifications of interest explicitly - the observer could narrow down what they are interested in
  • Encapsulating complex update semantics - might need a ChangeManager to deal with complex subject/observer relationships and can define an update strategy
  • Combining the Subject and Observer classes
• JDK Example: java.util.Observer and java.util.Observable
• GoF Reference (293)
• Example files are here

• 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 Ojbect nextElement();
  }
  

  In JDK 1.2 and above:

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

• Example files are here

What is architecture?

The highest level of abstraction in your design.

a description of the subsystems and components of a software system and the relationships between them

Components and subsystems can be shown from different views

• Topological
• Behavioral/Operational
• Data Flow
• Computing Environment
• Process Environment

Patterns fit into the context of the architecture.

Dictionary definitions:

1. the art or science of building; specifically : the art or practice of designing and building structures and especially habitable ones
2. formation or construction as or as if as the result of conscious act, a unifying or coherent form or structure
3. a method or style of building
4. the manner in which the components of a computer or computer system are organized and integrated

SEI definitions:

1. Bass, Clements, and Kazman. Software Architecture in Practice, Addison-Wesley 1997: The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.
2. Booch, Rumbaugh, and Jacobson, 1999: An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition (The UML Modeling Language User Guide, Addison-Wesley, 1999).
3. Software Architecture: An abstract system specification consisting primarily of functional components described in terms of their behaviors and interfaces and component-component interconnections. The interconnections define provide by which components interact.

Architectural Patterns are like the Software patterns we have been studying, except they are on a higher level

An architectural pattern is the fundamental structural organization of the system

Deals with subsystems and their interactions - the rules and guidelines for how they interact.

Comes from the Smalltalk-80 user interface design of user interfaces

Model - application object, the core data and functionality of the application. The model should not know about which view is using it. This allows you to move from a Text User Interface (TUI) to a Graphical User Interface (GUI) without changing the Model.

View - screen presentation. This could be a command line interface, a JSP/Servlet, a Swing Application, or a backend interface. The view will know about the Model, but doesn't necessarily have to have a reference to the model directly.

Controller - defines the way the View reacts to user input. Also decides whether requests are sent to the view or model. Should know about (and enforce) the relationships between views. Should decide whether a model gets updated or not. Many times, the Model will use a Command pattern to accept changes from the View.

Based on subscribe/notify. The view can subscribe to the model, and ensure that it will get notified. This is the Observer pattern. Views can be nested, in a CompositeView (using the Composite pattern). The View relates to the Controller via the Strategy design pattern. Factory Method can be used to specify the default controller class for a view, and Decorator could add scrolling or other GUI elements to a view.

Example files are here

Revised: 2003/2/23