COMS W4156: Advanced
Software Engineering
Prof. Gail Kaiser
Kaiser+4156@cs.columbia.edu
http://bank.cs.columbia.edu/classes/cs4156/
October 14, 2009
COMS W4156
1
Topics covered in this lecture
• General Design Goals
• Design Patterns
October 14, 2009
COMS W4156
2
Design Goals
October 14, 2009
COMS W4156
3
Design Goals
• Within a class (or component)
– High Cohesion
– Completeness
– Convenience
– Clarity
– Consistency
• Across classes (or components)
– Low Coupling
October 14, 2009
COMS W4156
4
Cohesion and Coupling
• Cohesion is a property or characteristic of an
individual unit
• Coupling is a property of a collection of units
• High cohesion GOOD, high coupling BAD
• Design for change:
– Reduce interdependency (coupling): You don't
want a change in one unit to ripple throughout
your system
– Group functionality (cohesion): Easier to find
things, intuitive metaphor aids understanding
October 14, 2009
COMS W4156
5
Cohesion
• The measure of strength of the association of elements within
a unit
• Cohesion scale:
–
–
–
–
–
–
–
Functional cohesion
Sequential cohesion
Communicational cohesion
Procedural cohesion
Temporal cohesion
Logical cohesion
Coincidental cohesion
October 14, 2009
(strongest, most desirable)
(weakest, undesirable)
COMS W4156
6
Cohesion
• Coincidental cohesion - elements have no
meaningful relationship to one another
• Logical cohesion - elements perform similar
activities, but the activities to be executed are
chosen from outside the unit
• Temporal cohesion - elements are related in
time (all should be done together)
October 14, 2009
COMS W4156
7
Cohesion
• Communicational cohesion - elements
perform different functions, but each function
references the same input or output
information
• Sequential (or informational) cohesion elements are related such that output data
from one serves as input data to the next
• Functional cohesion - elements contribute to
a single, well-defined task
October 14, 2009
COMS W4156
8
Coupling
• A measure of the interdependence of one software
unit to another
• Coupling scale
–
–
–
–
–
Content coupling
Common coupling
Control coupling
Stamp coupling
Data coupling
(worst)
(best / minimal needed
coupling)
– No direct coupling
October 14, 2009
COMS W4156
9
Coupling
• No Direct Coupling - Independent
• Data Coupling - Communicate by passing
parameters
• Stamp Coupling - Communicate via a passed
data structure that contains more information
than necessary for the two units to perform
their functions
October 14, 2009
COMS W4156
10
Coupling
• Control Coupling - Communicate using at least one
"control flag"
• Common Coupling - Share the same global data
area
• Content Coupling –
– One unit changes a statement in another (usually
applicable only to interpreted languages)
– One unit references or alters data contained inside another
– One unit branches into another
October 14, 2009
COMS W4156
11
Design Goals
• Within a class (or component)
– High Cohesion
– Completeness
– Convenience
– Clarity
– Consistency
• Across classes (or components)
– Low Coupling
October 14, 2009
COMS W4156
12
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, …
October 14, 2009
COMS W4156
13
Separation of Concerns
•
“The programmer is having to do several things at
the same time:
1. describe what is to be computed;
2. organize the computation sequencing into small steps;
3. organize memory management during the computation.
•
Ideally, the programmer should be able to
concentrate on one of the three tasks (describing
what is to be computed) without being distracted by
the other two, more administrative, tasks.” [Chris
Reade, Elements of Functional Programming, 1989]
October 14, 2009
COMS W4156
14
Design Patterns
October 14, 2009
COMS W4156
15
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
October 14, 2009
COMS W4156
16
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
October 14, 2009
COMS W4156
17
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();
}
}
October 14, 2009
COMS W4156
18
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
October 14, 2009
COMS W4156
19
Non-Software Proxy Pattern
October 14, 2009
COMS W4156
20
Software Proxy Pattern
October 14, 2009
COMS W4156
21
Discussion: Proxy
• Maintains a reference that lets it access the real subject
• Provides an interface identical to the 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
– …
October 14, 2009
COMS W4156
22
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, …
October 14, 2009
COMS W4156
23
Proxy Pattern Example
October 14, 2009
COMS W4156
24
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
October 14, 2009
COMS W4156
25
Non-Software Façade Pattern
October 14, 2009
COMS W4156
26
Software Façade Pattern
October 14, 2009
COMS W4156
27
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
October 14, 2009
COMS W4156
28
Façade Pattern Example
October 14, 2009
COMS W4156
29
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. “
October 14, 2009
COMS W4156
30
History of
Software Design Patterns
• Arose from frameworks like Model-ViewController (MVC) used in early OO programming,
notably Smalltalk
• “Gang of Four” (GoF): Erich Gamma, Richard
Helm, Ralph Johnson, John Vlissides
• Design Patterns: Elements of Reusable ObjectOriented Software (1995) – described 23 patterns
(observed, not invented)
• Many conferences, symposia, books, …
October 14, 2009
COMS W4156
31
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]
October 14, 2009
COMS W4156
32
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
October 14, 2009
COMS W4156
33
Design Pattern Elements (Expanded)
•
•
•
•
•
•
•
•
•
•
•
•
•
name and classification
intent
also known as
motivation
applicability
structure
participants
collaborations
consequences
implementation
sample code
known uses
related patterns
October 14, 2009
COMS W4156
34
Original Catalog of Patterns
Purpose
Creational
Scope
Structural
Behavioral
Class
Abstract Method
Adapter (class)
Interpreter
Template Method
Object
Abstract Factory
Builder
Prototype
Singleton
Adapter (object)
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Chain of
Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
October 14, 2009
COMS W4156
35
Creational Patterns
• Concerned with instantiation
• Create objects for you, rather than having you
instantiate objects directly
October 14, 2009
COMS W4156
36
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
October 14, 2009
COMS W4156
37
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
October 14, 2009
COMS W4156
38
Non-Software Factory Method Pattern
October 14, 2009
COMS W4156
39
Software Factory Method Pattern
October 14, 2009
COMS W4156
40
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)
October 14, 2009
COMS W4156
41
Factory Method Pattern Example
class 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) {
//...
}
}
Complex c = Complex.fromPolar(1, pi);
October 14, 2009
COMS W4156
42
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()
October 14, 2009
COMS W4156
43
Non-Software Abstract Factory Pattern
October 14, 2009
COMS W4156
44
Software Abstract Factory Pattern
October 14, 2009
COMS W4156
45
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, deployment descriptor, administrative
GUI, etc.)
October 14, 2009
COMS W4156
46
Abstract Factory Pattern Example
October 14, 2009
COMS W4156
47
Singleton Pattern
• Allow for only one instance of a given class to
ever exist (encapsulates that the number of
instances is constrained)
• Provides a mechanism to obtain this instance
that any client can access
• Examples include objects needed for logging,
communication, database access, etc.
October 14, 2009
COMS W4156
48
Non-Software Singleton Pattern
October 14, 2009
COMS W4156
49
Software Singleton Pattern
October 14, 2009
COMS W4156
50
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 loadbalancing
October 14, 2009
COMS W4156
51
Singleton Pattern Example
October 14, 2009
COMS W4156
52
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)
• …
October 14, 2009
COMS W4156
53
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
October 14, 2009
COMS W4156
54
Structural Patterns
• Proxy - a class functioning as an interface to
another thing
• Façade - creates 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
October 14, 2009
COMS W4156
55
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 do so
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
October 14, 2009
COMS W4156
56
Non-Software Adapter Pattern
October 14, 2009
COMS W4156
57
Software Adapter Pattern
October 14, 2009
COMS W4156
58
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
October 14, 2009
COMS W4156
59
Adapter Pattern Example
October 14, 2009
COMS W4156
60
Individual Object Adapter
October 14, 2009
COMS W4156
61
Aggregate Adapter
October 14, 2009
COMS W4156
62
Object Adapter
October 14, 2009
COMS W4156
63
Class Adapter
October 14, 2009
COMS W4156
64
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 finegrained objects efficiently (e.g., each character object in a
word processor shares reference to same object with font,
formatting, etc.)
• …
October 14, 2009
COMS W4156
65
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
October 14, 2009
COMS W4156
66
Behavioral Patterns
• Observer (Publish/Subscribe or Event
Listener) - objects register to observe an
event that may be raised by another object
• Mediator - simplifies communication between
classes
October 14, 2009
COMS W4156
67
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
October 14, 2009
COMS W4156
68
Non-Software Observer Pattern
October 14, 2009
COMS W4156
69
Software Observer Pattern
Subject
Attach (Observer)
Detach (Observer)
Notify ()
Observer
Update ()
for all o in observers
o -> Update ()
ConcreteObserver
ConcreteSubject
GetState ()
subjectState
October 14, 2009
return subjectState
Update ()
observerState =
subject -> GetState ()
observerState
COMS W4156
70
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)
October 14, 2009
COMS W4156
71
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
October 14, 2009
COMS W4156
72
Example: Multiple Displays Enabled by
Observer
50
D
A
C
25
B
0
A
B
C
D
Subject
Observer 1
October 14, 2009
A:
B:
C:
D:
40
25
15
20
COMS W4156
Observer 2
73
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
October 14, 2009
COMS W4156
74
Non-Software Mediator Pattern
October 14, 2009
COMS W4156
75
Software Mediator Pattern
October 14, 2009
COMS W4156
76
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)
October 14, 2009
COMS W4156
77
Mediator Pattern Example
October 14, 2009
COMS W4156
78
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 –
iterate through the elements of an aggregate object
sequentially without exposing its underlying representation
October 14, 2009
COMS W4156
79
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; lets 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
• …
October 14, 2009
COMS W4156
80
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
• Sample Java and C++ code for all patterns
http://www.vincehuston.org/dp/, also see “Who ya
gonna call?”
October 14, 2009
COMS W4156
81
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
• A great source of intuition particularly wrt testing and
cost-benefit issues, but only covers subset of
patterns, at http://www.netobjectivesrepository.com/
October 14, 2009
COMS W4156
82
Upcoming Assignments
October 14, 2009
COMS W4156
83
Upcoming Assignments
• First Iteration Plan due Tuesday 19 October.
• First Iteration Progress Report due Tuesday 26
October.
• First Iteration Demo Wednesday 3 November –
Thursday 11 November.
• First Iteration Final Report due Friday 12
November.
October 14, 2009
COMS W4156
84
COMS W4156: Advanced Software
Engineering
Prof. Gail Kaiser
Kaiser+4156@cs.columbia.edu
http://bank.cs.columbia.edu/classes/cs4156/
October 14, 2009
COMS W4156
85