team 6 the unparseables
Skip this Video
Download Presentation
Team 6 “The Unparseables”

Loading in 2 Seconds...

play fullscreen
1 / 25

Team 6 “The Unparseables” - PowerPoint PPT Presentation

  • Uploaded on

Team 6 “The Unparseables” . Design Patterns . Chain of Responsibility Observer Flyweight. 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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Team 6 “The Unparseables” ' - kailey

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
team 6 the unparseables

Team 6 “The Unparseables”

Design Patterns

Chain of Responsibility



chain of responsibility
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.


    • 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.

Example (gravel filter)

The finest gravel is collected in the sill



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



  • 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.


    • 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.


    • 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.


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.


import java.beans.PropertyChangeListener;

import java.util.ArrayList;

import java.util.Iterator;

import java.util.List;

public class MyModel {

private List<Person> persons = new ArrayList<Person>();

private List<PropertyChangeListener> listener = new ArrayList<PropertyChangeListener>();

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;




public List<Person> 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





public void addChangeListener(PropertyChangeListenernewListener) {






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.



  • 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.




    • 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.




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.




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.




Design Patterns: Elements of Reusable Object-Oriented Software