24 october 2006kaiser: coms w4156 fall 20061 coms w4156: advanced software engineering prof. gail...

24 October 2006 Kaiser: COMS W4156 Fall 2006 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

http://york.cs.columbia.edu/classes/cs4156/

mailto:[email protected]



Design Patterns

• A design pattern is a way of reusing abstract knowledge about a problem and its solution

• A pattern is a description of the problem and the essence of its solution

• A pattern should be sufficiently abstract to be reused in different settings

• Patterns often rely on object characteristics such as inheritance and polymorphism


History of Design Patterns

• Architect Christopher Alexander– A Pattern Language (1977)– Several other books…– www.patternlanguage.com

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. “

http://www.patternlanguage.com/


Software Developers’ Lament

• “If only software engineering could be more like X ...”, where X is any design-intensive profession with a longer and apparently more successful history than software

• It is therefore both comforting and troubling to discover that the same fundamental philosophical, methodological and pragmatic concerns arise in all of these Xs


History of Software Design Patterns

• “Gang of four”• Erich Gamma • Richard Helm• Ralph Johnson• John Vlissides

– Design Patterns: Elements of Reusable Object-Oriented Software (1995) – described 23 patterns (observed, not invented)

• Many conferences, symposia, books by many


Design Patterns“A design pattern systematically names, motivates, and explains a

general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.”

Pattern elements: • Name• Problem description• Solution description

– Not a concrete design but a template for a design solution that can be instantiated in different ways

• Consequences– The results and trade-offs of applying the pattern


Types of Patterns• Creational

– Concerned with instantiation– Create objects for you, rather than having you instantiate objects

directly, giving your program more flexibility in deciding which objects need to be created for a given case

– Class-creation patterns use inheritance in the instantiation process while Object-creation patterns use delegation

• Structural– Concerned with composition– Help you compose groups of objects into larger structures– Use inheritance to compose interfaces or define other ways to compose

objects to obtain new functionality• Behavioral

– Concerned with communication– Help you define the communication between objects and how the flow is

controlled


The Abstract Factory Pattern

• Creational• Creates an instance of any of a family of classes• Provide an interface for creating families of related or

dependent objects without specifying their concrete classes

• Useful for families of products and to enforce families of products that must be used together

• Promotes consistency among products • Example: DocumentCreator class that provides

interfaces to create instances of several kinds of documents, e.g., createLetter() and createResume()



• If you want to construct instances of a class, where the class is selected at run-time, then1. Create one abstract factory class for each existing

class (or group of related classes) you wish to create

2. Have a polymorphic “create instance” method on each abstract factory class, conforming to a common method signature, used to create instances of the corresponding class

3. Store and pass around instances of the abstract factory class to control selection of the class to create


Other Creational Patterns

• Builder – separates complex object construction from its representation, so that same construction process can create different representations

• Factory Method – creates an instance of any of several derived classes, lets a class defer instantiation to subclasses

• Prototype – specify the kind of objects to create using a prototypical instance, a fully initialized instance is copied or cloned

• Singleton – a class of which only a single instance can exist, ensure the class has only one instance and provide a global point of access to it


The Façade Pattern

• Structural• A single class that represents an entire subsystem• Provide a unified interface to a set of interfaces in a

subsystem• Defines a higher-level interface that makes the

subsystem easier to use• Applicable when need to provide a simple interface to a

complex system, to shield clients from subsystem components, or to provide a single entry point to a library or layer

• Often semantic wrapper of existing [legacy] objects• Example: Java Font and Graphics classes front for

dozens of classes for parsing font files and rendering text into geometric outlines and ultimately into pixels


The Façade Pattern


The Proxy Pattern

• Structural• Provide a surrogate or placeholder for another object to

control access to it• Several types:

– Virtual (or Lazy) – lazy instantiation, useful for holding off on creating resource-hungry objects until functionality actually needed by a client, also Copy-on-write

– Remote – hide the fact that the real object is in another address space and provide communication mechanisms between remote objects

– Synchronization – multiple accesses to target object, also Caching– Access (or Protection) – checks client’s access permissions, also

Firewall– Smart (or Decorator) – provide additional functionality to top of proxied

object

• Example: Reference counting pointer object


The Proxy Pattern


The Adapter Pattern• Structural• Convert or wrap the interface of a class into

another interface clients expect• Lets classes work together that could not

otherwise because of incompatible interfaces• Makes heavy use of delegation• Example: Convert the interface of a

Document Object Model of an XML document into a tree structure that can be displayed.


The Adapter Pattern


Other Structural Patterns

• Bridge – separates an object’s interface from its implementation, decouples an abstraction from its implementation so that the two can vary independently

• Composite – compose objects into a tree structure of simple and composite objects to represent part-whole hierarchies, lets clients treat individual objects and compositions of objects uniformly

• Decorator – attach additional responsibilities to an object dynamically, provides a flexible alternative to subclassing for extending functionality

• Flyweight – use sharing to support large numbers of fine-grained objects efficiently


The Observer Pattern

• Behavioral• Separates the display of object state from the object

itself, e.g., when multiple distinct display views of state are needed (model-view-controller paradigm)

• Define a one to many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically

• Useful for dynamic relationships between objects, hook up a new observer while the program is running, unhook it later

• However, optimizations to enhance display performance may be impractical


Example:Multiple displays enabled by Observer

Subject

A: 40B: 25C: 15D: 20

Observer 1 Observer 2

0

50

25

A B C D

A

B

C

D


The Observer Pattern

Subject Observer

Attach (Observer)Detach (Observer)Notify ()

Update ()

ConcreteSubject

GetState ()

subjectState

ConcreteObserver

Update ()

observerState

return subjectState

for all o in observers o -> Update ()

observerState = subject -> GetState ()


Styles of Observer Notification

• Push – observed “publishes” a change and observers get notified of the change

• Pull – observers repeatedly poll the observed to note changes

• The observed does not know anything about the observers

• Basis for publish-subscribe messaging architectures


The Mediator Pattern

• Behavioral• Define an object that encapsulates how a set of

objects interact• Promotes loose coupling by keeping objects from

referring to each other explicitly, and allows to vary their interaction independently

• Defines simplified communication between classes where otherwise the interactions may be complex, with code buried inside those classes

• May limit subclassing, centralizes control • Example: Instant messaging


The Mediator Pattern


More Behavioral Patterns• Chain of Responsibility – a way of passing a request

along a chain of objects, avoid coupling the sender of the request to its receiver by giving more than one object a chance to handle the request

• Command – encapsulate a command request as an object, used to parameterize clients with different requests, queue or log requests, and support undoable operations

• Interpreter – given a language, define a representation for its grammar along with an interpreter for sentences in this language

• Iterator – sequentially access the elements of a collection, access the elements of an aggregate object sequentially without exposing its underlying representation


More Behavioral Patterns

• Memento – capture, externalize and restore an object’s internal state (without violating encapsulation)

• State – alter an object’s behavior when its internal state changes, the object will appear to change its class

• Strategy – define a family of algorithms, encapsulate each one inside a class, and make them interchangeable, let’s the algorithm vary independently from clients that use it

• Template Method – define the skeleton of an algorithm and defer (some) exact steps to subclasses, lets subclasses refine certain steps of an algorithm without changing the algorithm’s structure

• Visitor – defines a new operation on the elements of an object’s structure without changing its class


Where to Get Code Examples

• GoF book defines 23, with sample C++ and Smalltalk• Sample C# code for all patterns at http://

www.dofactory.com/Patterns/Patterns.aspx • Sample Java code for all patterns at

http://www.patterndepot.com/put/8/JavaPatterns.htm • Some sample code in various languages (some each C+

+, Java, C#, Perl, Python) at http://en.wikipedia.org/wiki/Design_Patterns

• GOF member John Vlissides has another book, Pattern Hatching: Design Patterns Applied (1998), about using patterns – but requires C++ intimacy

• Other authors have proposed various additional patterns, often with code

http://www.dofactory.com/Patterns/Patterns.aspx

http://www.dofactory.com/Patterns/Patterns.aspx

http://www.patterndepot.com/put/8/JavaPatterns.htm

http://en.wikipedia.org/wiki/Design_Patterns


Guiding Themes

• Program to an interface and not to an implementation– Define the top of any class hierarchy with an abstract class,

which implements no methods, but simply defines the methods the class will support

– Then in all your derived classes, you have more freedom to implement these methods as most suits your purposes

• Favor object composition over inheritance– Construction of objects that contain or encapsulate several other

objects– Your new object can have the interface that is best for what you

want to accomplish without having all the methods of the parent classes


Project Deliverables

• Project concept (P/F)• Revised concept (P/F)• First iteration (25%)

– 1st iteration plan (5%)– 1st iteration progress

report (5%)– 1st iteration demo (5%)– 1st iteration final report

(10%)

• Second iteration (25%)– 2nd iteration plan – Code inspection– 2nd iteration progress

report – 2nd iteration demo– 2nd iteration final report


Demo due November 8-14

• 15-20 minutes total including any "setup" time• Schedule

– With Prof. Kaiser for in/after class time (Thursday November 9th or Tuesday November 14th, 11-12:15 or 12:30-1:30)

– With your TA otherwise• Be prepared to show the code corresponding to

any portion of the demo system• Be prepared to describe your system's utilization

of the component model framework.• One representative of each pair must be present

at the demo


First Iteration Progress Report due November 14th

• The purpose of this assignment is to revise your requirements, architecture and component-level design to reflect realityreality, and to evaluate your use of the chosen component model framework.

• Revise your requirements:– Include your complete set of requirements (use cases

or user stories).– For any requirements that changed, show the new

version of the requirement and explain the difference.– Indicate any requirements that have been dropped. – If any features are only partially completed, describe

what does and does not work.



• Revise your high-level architecture and lower-level design.

• Diagram and explain the process-level architecture of your system, including all communication paths.

• Describe the major expected "workflows" that a user would achieve with the system and explain the corresponding interactions among the architectural units during those scenarios.

• Consider both end-users and administrators, if applicable.



• For each internal architectural subsystem, break down into components.

• Diagram and explain the use of interfaces and control and data flows among the components.

• Indicate any previously planned subsystems, communication paths, components, interfaces, etc. that are "missing" for whatever reason from your system.

• Explain the roles of any external "systems" - e.g., databases, web browsers, facilities provided by the component model framework.



• Describe how you leveraged the main aspects of the component model framework

• Or "worked around" them if that is indeed what you did. • Consider the main services provided by the framework,

and discuss any you considered using - both those you did end up using and those you did not (and why not).

• Discuss any "challenges" that arose in deploying or utilizing the framework, and how you resolved them.

• State which specific implementation of the component model framework you used, including version number and where you got it from (e.g., url).


DeliverablesAn archive (e.g., a .zip file) with a main document that includes:1. Cover page (1 page): Indicate the name of your team and list all

team members with their full names and email addresses. Indicate that this document presents your First Iteration Final Report.

2. Revised Requirements (no maximum page limit). 3. Revised high-level architecture and component-level design (no

maximum page limit).4. Component-model framework (no maximum page limit).5. Controversies (maximum 1 page).Additional files in the archive should include:6. The complete code for your system. Include a README file with

installation instructions and a brief description of how to run the system.


Upcoming

• First iteration progress report due October 31st

• First demo week November 8-14

• First iteration final report due November 14


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


24 october 2006kaiser: coms w4156 fall 20061 coms w4156: advanced software engineering prof. gail...

Documents

design solution

coms w4156

pattern slide

recurring design problem

general design

concrete design

gail kaiser kaiser

objectcreation patterns