october 14, 2009coms w41561 coms w4156: advanced software engineering prof. gail kaiser...

October 14, 2009 COMS W4156 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

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

mailto:[email protected]



Topics covered in this lecture

• General Design Goals• Design Patterns


Design Goals


Design Goals

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

• Across classes (or components)– Low Coupling


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


Cohesion

• The measure of strength of the association of elements within a unit

• Cohesion scale:– Functional cohesion (strongest, most desirable)– Sequential cohesion– Communicational cohesion– Procedural cohesion– Temporal cohesion– Logical cohesion– Coincidental cohesion (weakest, undesirable)


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)


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


Coupling

• A measure of the interdependence of one software unit to another

• Coupling scale– Content coupling (worst)– Common coupling– Control coupling– Stamp coupling– Data coupling (best / minimal needed

coupling)– No direct coupling


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


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


Design Goals

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

• Across classes (or components)– Low Coupling


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, …

http://java.sun.com/docs/codeconv/

http://www.possibility.com/Cpp/CppCodingStandard.html


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]


Design Patterns


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


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 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– …


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 (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 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 PatternsPurpose

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) { //... }}

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, deployment descriptor, administrative GUI, etc.)


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)

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


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


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 that may be raised by another object

• Mediator - simplifies 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 – iterate through 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; 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

• …


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?”


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/

Upcoming Assignments


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.


COMS W4156: Advanced Software Engineering

Prof. Gail [email protected]



october 14, 2009coms w41561 coms w4156: advanced software engineering prof. gail kaiser...

Documents

coupling cohesion

coms w41565 cohesion

coms w41566 cohesion

direct coupling slide

interdependency coupling

unit cohesion scale

logical cohesion elements

functional cohesion