16 october 2007kaiser: coms w4156 fall 20071 coms w4156: advanced software engineering prof. gail...

16 October 2007 Kaiser: COMS W4156 Fall 2007 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

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



Design

• Within a class (or component)– High Cohesion– Completeness– Convenience– Clarity– Consistency

• Across classes (or components)– Low Coupling


Design Pattern

• A general repeatable solution to a commonly occurring problem

• A description of the problem and the essence of its solution

• Should be sufficiently abstract to be reused in different settings

• Designed to avoid re-design• Allow developers to communicate using well-

known, well understood names for software interactions


Naming Conventions

• Most modern programming languages supply their own naming conventions (learn it, use it! – Java, C++, C#)

• Otherwise, choose a scheme at design-time and stick to it at coding-time

• For components, interfaces, classes, types, methods, exceptions, members, parameters, variables, …


Example: Delegation

• An object outwardly expresses certain behavior but in reality delegates responsibility for implementing that behavior to an associated object

• Very general concept, refined in several more specific design patterns


Example: Delegation class A { void f() { System.out.println("A: doing f()"); } void g() { System.out.println("A: doing g()"); } } class C { // delegation A a = new A(); void f() { a.f(); } void g() { a.g(); } // normal attributes X x = new X(); void y() { /* do stuff */ } } public class Main { public static void main(String[] args) { C c = new C(); c.f(); c.g(); } }


Example: Proxy Pattern

• An object functions as an interface to another object

• Provide a surrogate or placeholder that uses an extra level of indirection to support distributed, controlled, or intelligent access to an object

• In its most general form, a proxy is <something> functioning as an interface to <something else>. The <something else> could be anything: a network connection, a large object in memory, a file, or some other resource


Non-Software Proxy Pattern


Software Proxy Pattern


Discussion: Proxy

• Maintains a reference that lets it access the real subject• Provides an interface identical to subject's so that a

proxy can be substituted for the real subject• Controls access to the real subject and may be

responsible for creating and deleting it • May also:

– Count the number of references to the real object so that it can be freed automatically when there are no more references

– Load a persistent object into memory when it's first referenced– Check that the real object is locked before it is accessed to

ensure that no other object can change it– …


Types of Proxies

• Remote proxies are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space

• Virtual proxies are placeholders for “expensive to create” or “resource hungry” objects, may cache additional information about the real subject so that they can postpone accessing it

• Protection proxies check that the caller has the access permissions required to perform a request and may provide different clients with different levels of access

• Others: copy-on-write, cache, synchronization, …


Proxy Pattern Example


Example: Façade Pattern

• A single class that represents an entire subsystem or library

• Provides a unified interface to a set of interfaces

• May simplify by providing convenient methods for common tasks that internally involve multiple classes/methods

• Often semantic wrapper of existing [legacy] objects


Non-Software Façade Pattern


Software Façade Pattern


Discussion: Façade

• Knows which subsystem classes are responsible for a request and delegates client requests to appropriate objects

• Subsystem classes handle work assigned by façade but have no knowledge of the façade and keep no reference to it

• Reduces dependencies of outside code on the inner workings of a subsystem

• May reduce learning curve for novice users but be insufficient for power users

Façade Pattern Example


History of “Design Patterns”

• (Building) 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. “


History of Software Design Patterns

• Arose from frameworks like Model-View-Controller used in early OO programming (notably Smalltalk)

• “Gang of Four” (GoF): 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, …


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.” [GoF]


Design 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


Design Pattern Elements (Expanded)

• name and classification• intent• also known as• motivation• applicability• structure• participants• collaborations• consequences• implementation• sample code• known uses• related patterns

Original Catalog of Patterns

Purpose

Creational Structural Behavioral

Scope Class Abstract Method Adapter (class) InterpreterTemplate Method

Object Abstract FactoryBuilderPrototypeSingleton

Adapter (object)BridgeCompositeDecoratorFaçadeFlyweightProxy

Chain of ResponsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor


Creational Patterns

• Concerned with instantiation

• Create objects for you, rather than having you instantiate objects directly


Creational Patterns

• Factory Method – creates an instance of several derived classes

• Abstract Factory – creates an instance of several families of classes

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


Factory Method Pattern

• Define an interface for creating an object, but let subclasses decide which class to instantiate

• Lets a class defer instantiation to subclasses• Common in toolkits and frameworks where

library code needs to create objects of types that may be subclassed by applications using the framework

• More generally, the term factory method is often used to refer to any method whose main purpose is creation of objects


Non-Software Factory Method Pattern


Software Factory Method Pattern


Discussion: Factory Method

• Defines a "virtual" constructor• Unlike a constructor, factory methods can

have different and more descriptive names • Unlike a constructor, an existing object

might be reused, instead of a new object created (object pooling)

• The new operator considered harmful (make all constructors private or protected)


Factory Method Pattern Exampleclass Complex { public static Complex fromCartesian(double real, double

imag) { return new Complex(real, imag); } public static Complex fromPolar(double rho, double theta)

{ return new Complex(rho * cos(theta), rho *

sin(theta)); } private Complex(double a, double b) { //... }}

// Same as fromCartesian(-1, 0) Complex c = Complex.fromPolar(1, pi);


Abstract Factory Pattern

• 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()


Non-Software Abstract Factory Pattern


Software Abstract Factory Pattern


Discussion: Abstract Factory

• Coordinates the instantiation of sets of objects that have varying implementations in such a way that only legitimate combinations of instances are possible, and hides these concrete instances behind a set of abstractions

• Hides from consuming (client) objects:– The number of sets of instances supported by the

system – Which set is currently in use – The concrete types that are instantiated at any point – The issue upon which the sets vary (might be

determined from a config file)


Abstract Factory Pattern Example


Singleton Pattern

• Allow for only one instance of a given class to ever exist (encapsulates that the number of instances is constrained)

• Provide a mechanism to obtain this instance that any client can access

• Examples include objects needed for logging, communication, database access, etc.


Non-Software Singleton Pattern


Software Singleton Pattern


Discussion: Singleton

• Typically instantiated lazily - the instance is not created until it is needed, perhaps never

• If stateful, analogous to a global variable (with many of the same problems as a global variable, e.g., unexpected side-effects)

• May need to ensure thread safety (if it is possible for one thread to be engaged in the creation of the instance while another is checking for null, possibly resulting in two instances)

• Can scale to two, three or more instances for load-balancing


Singleton Pattern Example


Other Creational Patterns

• Builder: separate the construction of a complex object from its representation so that the same construction process can create different representations

• Prototype: specify the kind of objects to create using a prototypical instance, a fully initialized instance is copied or cloned (not the same as prototypes used during software engineering lifecycle requirements phase)

• …


Structural Patterns

• Concerned with composition

• Help you compose groups of objects into larger structures

• Eases design by identifying a simple way to realize relationships between entities


Structural Patterns

• Proxy - a class functioning as an interface to another thing

• Façade - create a simplified interface of an existing interface to ease usage for common tasks

• Adapter – 'adapts' one interface for a class into an interface that a client expects


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

another interface clients expect• Useful when an already existing class

provides some or all of the services needed but does not provide the interface needed

• Lets classes work together that could not otherwise because of incompatible interfaces

• Example: Convert the interface of a Document Object Model of an XML document into a tree structure that can be displayed


Non-Software Adapter Pattern


Software Adapter Pattern


Discussion: Adapter

• Creates an intermediary abstraction that translates, or maps, the old component to the new system

• Makes heavy use of delegation where the delegator is the adapter (or wrapper) and the delegate is the class being adapted

• Responsible for handling any logic necessary to transform data into a form that is useful for the consumer

• Can wrap either an individual object instance or an aggregation of multiple object instances, and operate at either object or class level


Adapter Pattern Example


Individual Object Adapter


Aggregate Adapter


Object Adapter


Class Adapter


Other Structural Patterns• Bridge – separates a varying entity from a varying behavior,

decouples an abstraction from its implementation so that the two can vary independently (analogous to branching conditional logic)

• 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 (e.g., root vs. internal vs. leaf node)

• Decorator – attach additional behavior(s) to an object dynamically, provides a flexible alternative to subclassing for extending functionality (e.g., pre and post processing)

• Flyweight – use sharing to support large numbers of fine-grained objects efficiently (e.g., each character object in a word processor shares reference to same object with font, formatting, etc.)

• …


Behavioral Patterns

• Concerned with communication

• Identify common communication patterns between objects and realize these patterns

• Help you define the communication between objects and how the flow is controlled


Behavioral Patterns

• Observer (Publish/Subscribe or Event Listener) - objects register to observe an event which may be raised by another object

• Mediator - defines simplified communication between classes


Observer Pattern

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

• 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


Non-Software Observer Pattern


Software 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 ()


Discussion: Observer

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

• Often associated with the model-view-controller (MVC) paradigm: separates the display of object state from the object itself, e.g., when multiple distinct display views of state are needed

• Possible optimizations such as event compression (only sending a single change broadcast after a series of consecutive changes has occurred)


Styles of Observer Notification

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

• Pull – observers repeatedly poll the subject to note changes

• The subject does not know anything about the observers

• A single observer may monitor multiple subjects


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


Mediator Pattern

• 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

• Example: Instant messaging


Non-Software Mediator Pattern


Software Mediator Pattern


Discussion: Mediator

• Design an intermediary to decouple and orchestrate many peers, promotes the many-to-many relationships between interacting peers to "full object status“

• Like façade, provides a unified interface to a set of interfaces in a subsystem, different from façade in that the underlying classes interact with each other through the mediator

• Façade defines a simpler interface to a subsystem, it doesn't add new functionality, and it is not known by the subsystem classes (i.e., it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa)


Mediator Pattern Example


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

along a chain of objects, or choosing among a set 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 – implements a specialized computer language grammar to solve a specific set of problems (e.g., SQL)

• 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/JavaPatternshtm • Sample Java and C++ code for all patterns

http://www.vincehuston.org/dp/, also “Who ya gonna call?”

• Some sample code in various languages at http://en.wikipedia.org/wiki/Design_Patterns, includes many patterns beyond original 23 (includes a new category of Concurrency Patterns)


Summary

• Design Patterns write down and catalog common interactions between objects (or classes, or components) that programmers have frequently found useful

• Primarily applicable to OO programming, but also applies to some non-OO programming

• Intuition: Non-Software Examples of Software Design Patterns

• Another great source of intuition particularly wrt testing and cost-benefit issues, but only covers subset of patterns, at http://www.netobjectivesrepository.com/


First Iteration Progress ReportDue Next Week!

• Tuesday 23 October, 10am

• Assignments posted on course website

• Submit via CourseWorks

• First Iteration Progress Report


Upcoming Deadlines

• First iteration demo “week” October 30th – November 8th (schedule with your TA)

• First iteration final report due November 9th • Midterm Individual Assessment posted Friday

November 9th • Midterm Individual Assessment due Friday

November 16th Reminder: reading Szyperski is optional, but

reading Patton is required (you’ll need for FIA) – bookstore is sending back unsold texts this week


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


16 october 2007kaiser: coms w4156 fall 20071 coms w4156: advanced software engineering prof. gail...

Documents

coms w4156

real object

new c c

class c

void g

void f

delegationan object

large object