Team 6 “The Unparseables” Design Patterns Chain of Responsibility Observer Flyweight 1

Chain of Responsibility Overview ◦ A client sends a request to process data to a chain of program units that if possible, will handle the request. ◦ If the program unit or “handler” cannot handle the request, it will pass the request to the next “handler” in the chain. 2

Motivation ◦ Chain the “handlers” and pass the request along the chain until an one of them is able to process it. ◦ It is data-driven ◦ Loosely coupled ◦ Each object on the chain shares a common interface for handling requests and for accessing its successor on the chain. 3

Example (gravel filter) 4 The finest gravel is collected in the sill

5 Structure

6

7

Problem There is a potential variable number of “handler” objects, and a stream of requests that must be handled. Efficiency could be a problem. 8

Sources esponsibility.aspx nsibility 9

Observer Overview ◦ Defines a one-to-many dependency between a subject object and any number of observer objects. ◦ Has two parts and they are subject and observer. ◦ The subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. 10

Motivation ◦ Encapsulate the core (or common or engine) components in a Subject abstraction, and the variable (or optional or user interface) components in an Observer hierarchy. ◦ Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. 11

Applicability: ◦ When the abstraction has two aspects with one dependent on the other. ◦ When the subject object doesn't know exactly how many observer objects it has. ◦ When the subject object should be able to notify it's observer objects without knowing who these objects are. 12

Structure 13

Example The Observer defines a one-to-many relationship so that when one object changes state, the others are notified and updated automatically. Some auctions demonstrate this pattern. 14

import java.beans.PropertyChangeListener; import java.util.ArrayList; import java.util.Iterator; import java.util.List; public class MyModel { private List persons = new ArrayList (); private List listener = new ArrayList (); public class Person { private String firstName; private String lastName; public Person(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } public String getFirstName() { return firstName; } public void setFirstName(String firstName) { this.firstName = firstName; } public String getLastName() { return lastName; } public void setLastName(String lastName) { this.lastName = lastName; notifyListeners(); } public List getPersons() { return persons; } public MyModel() { // Just for testing we hard-code the persons here: persons.add(new Person("Lars", "Vogel")); persons.add(new Person("Jim", "Knopf")); } private void notifyListeners() { for (Iterator iterator = listener.iterator(); iterator.hasNext();) { PropertyChangeListener name = (PropertyChangeListener) iterator.next(); name.propertyChange(null); } public void addChangeListener(PropertyChangeListener newListener) { listener.add(newListener); } 15

Problem In a complex system you want “maintain consistency between related objects”. This is not a trivial task, since coupling the objects together reduces reuse of each component. How can you maintain consistency, yet also maintain the loose coupling? Solution If you make the related classes observers, who look at a common repository of data for their state, you can maintain consistency and no observer knows about the others. The subject has methods to attach, detach, and update the observers in the event that its state changes. 16

Sources ◦ atterns/observer.html atterns/observer.html ◦ guru.com/blog/2011/01/09/observer-design- pattern/ guru.com/blog/2011/01/09/observer-design- pattern/ ◦ erver erver 17

Flyweight Overview ◦ The Flyweight Design Pattern is useful when there is the need for many, many objects to exist that share some information. ◦ Several thousand or even several hundred thousand objects might be needed, and this is usually very memory-consuming to keep track of. 18

Motivation ◦ A large number of objects take up a large amount of space ◦ Objects may contained shared intrinsic state that can be moved into shared objects ◦ If all of the objects share some intrinsic, invariant information that is constant among all of them, it can be removed from each object, and referenced. This object that contains all of the intrinsic information is called a flyweight object. 19

Structure 20

Example The public switched telephone network is an example of a Flyweight. There are several resources such as dial tone generators, ringing generators, and digit receivers that must be shared between all subscribers. A subscriber is unaware of how many resources are in the pool when he or she lifts the handset to make a call. All that matters to subscribers is that a dial tone is provided, digits are received, and the call is completed. 21

22

Problem Designing objects down to the lowest levels of system “granularity” provides optimal flexibility, but can be unacceptably expensive in terms of performance and memory usage. Discussion The Flyweight pattern describes how to share objects to allow their use at fine granularities without prohibitive cost. Each “flyweight” object is divided into two pieces: the state- dependent part, and the state-independent part. Intrinsic state is stored in the Flyweight object. Extrinsic state is stored or computed by client objects, and passed to the Flyweight when its operations are invoked. 23

Sources s/designpatterns/flyweightpattern.htm yweight Design Patterns: Elements of Reusable Object-Oriented Software 24

Thank you 25