Introduction to Patterns and Frameworks

Home , Proactor pattern, Software framework

OO Patterns Douglas C. Schmidt Patterns and Frameworks

Motivation for Patterns and Frameworks Douglas C. Schmidt What is a Pattern? A Framework? Professor Department of EECS

Pattern Categories [email protected] Vanderbilt University

www.cs.wustl.edu/ schmidt/ (615) 343-8197 Pattern Examples

Vanderbilt University 1

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Motivation for Patterns and Frameworks Overview of Patterns and Frameworks

Developing software is hard BLOB Patterns support reuse of software architecture and design STORE

Developing reusable – Patterns capture the static and dynamic structures and ATM software is even harder LAN collaborations of successful solutions to problems that arise when

DIAGNOSTIC STATIONS building applications in a particular domain Proven solutions include

patterns and frameworks Frameworks support reuse of detailed design and code

ATM www.cs.wustl.edu/ schmidt/ – A framework is an integrated set of components that collaborate MAN CLUSTER patterns.html to provide a reusable architecture for a family of related ATM BLOB LAN STORE applications

Together, design patterns and frameworks help to improve software

MODALITIES CENTRAL quality and reduce development time (CT, MR, CR) BLOB STORE – e.g., reuse, extensibility, modularity, performance

Vanderbilt University 2 Vanderbilt University 3 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Patterns of Learning Becoming a Chess Master

learning First learn the rules

Successful solutions to many areas of human endeavor are deeply rooted in patterns – e.g., names of pieces, legal movements, chess board geometry and orientation, etc. – In fact, an important goal of education is transmitting patterns of

from generation to generation Then learn the principles – e.g., relative value of certain pieces, strategic value of center In a moment, we’ll explore how patterns are used to learn chess squares, power of a threat, etc.

Learning to develop good software is similar to learning to play good

However, to become a master of chess, one must study the chess games of other masters – Though the consequences of failure are often far less dramatic! – These games contain patterns that must be understood, memorized, and applied repeatedly

There are hundreds of these patterns

Vanderbilt University 4 Vanderbilt University 5

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Becoming a Software Design Master Design Patterns

First learn the rules Design patterns represent solutions to problems that arise when – e.g., the algorithms, data structures and languages of software developing software within a particular context – i.e., “Pattern == problem/solution pair in a context”

Then learn the principles

– e.g., structured programming, modular programming, object Patterns capture the static and dynamic structure and collaboration oriented programming, generic programming, etc. among key participants in software designs – They are particularly useful for articulating how and why to However, to become a master of software design, one must study the designs of other masters resolve non-functional forces

– These designs contain patterns that must be understood, Patterns facilitate reuse of successful software architectures and memorized, and applied repeatedly designs

There are hundreds of these patterns

Vanderbilt University 6 Vanderbilt University 7 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Example: Stock Quote Service Structure of the Observer Pattern

Key Forces Intent SUBJECT REAL-TIME foreach o in observers loop MODEL o.update() MARKET 1. There may be many end loop Observer – Define a one-to-many DATA FEED observers 1Nupdate() dependency between Subject observers objects so that when one 2. Each observer may react notify() APPLICATION attach(observer) INDEPENDENT object changes state, all differently to the same detach(observer) APPLICATION its dependents are notification DEPENDENT notified and updated STOCK 3. The subject should be as Concrete automatically. QUOTES Observer decoupled as possible Concrete update() from the observers Subject subject OBSERVERS get_state() subject->get_state()

i.e., allow observers to subject_state_ change independently of return subject_state_ the subject

Vanderbilt University 8 Vanderbilt University 9

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Graphical Notation Collaboration in the Observer Pattern

Concrete Concrete Concrete Variations Subject Observer 1 Observer 2

PROCESS “Push” architectures combine THREAD set_state() control ﬂow and data ﬂow

notify() “Pull” architectures separate control ﬂow from data ﬂow update() OBJECT TEMPLATE : CLASS CLASS get_state()

update() get_state() INHERITS CONTAINMENT

Vanderbilt University 10 Vanderbilt University 11 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Design Pattern Descriptions Frameworks Main parts Pattern descriptions are often independent of 1. Frameworks are semi-complete applications 1. Name and intent programming language or Complete applications are developed by inheriting from, and 2. Problem and context implementation details instantiating parameterized framework components

3. Force(s) addressed Contrast with 2. Frameworks provide domain-speciﬁc functionality frameworks

4. Abstract description of structure and e.g., business applications, telecommunication applications, collaborations in solution window systems, databases, distributed applications, OS kernels 5. Positive and negative 3. Frameworks exhibit inversion of control at run-time consequence(s) of use

i.e., the framework determines which objects and methods to 6. Implementation guidelines and invoke in response to events sample code 7. Known uses and related patterns

Vanderbilt University 12 Vanderbilt University 13

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Class Libraries vs. Frameworks vs. Patterns Component Integration in Frameworks APPLICATION- LOCAL MATH SPECIFIC INVOCATIONS CLASSES Deﬁnition FUNCTIONALITY ADT Framework components are loosely

CLASSES DATABASE Class libraries APPLICATION CLASSES CODE coupled via callbacks GUI EVENT GLUE NETWORK – Self-contained, “pluggable” ADTs CLASSES Callbacks allow independently developed LOOP CODE IPC CLASSES EVENT software components to be connected Frameworks (A) CLASS LIBRARY ARCHITECTURE HANDLER (S) together – Reusable, “semi-complete” EVENT callback()

NETWORKING LOOP applications Callbacks provide a connection-point where ADT DISPATCHER generic framework objects can CLASSES GUI

APPLICATION- CALL Patterns EVENT LOOP communicate with application objects INVOKES SPECIFIC BACKS FUNCTIONALITY EVENT EVENT SENSOR MATH LOOP – Problem, solution, context – The framework provides the common CLASSES SYSTEM template methods and the application EVENT DATABASE CODE LOOP provides the variant hook methods (B) FRAMEWORK ARCHITECTURE

Vanderbilt University 14 Vanderbilt University 15 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Comparing Patterns and Frameworks Design Pattern Space

State Reactor/Proactor Singleton Patterns and frameworks Strategy I/O Strategy Cached Virtual Creational patterns Framework Filesystem are highly synergistic – i.e., neither is – Deal with initializing and conﬁguring classes and objects Asynchronous Completion Token Tilde ~ Expander /home/... subordinate

Protocol Acceptor Structural patterns Handler Event Dispatcher

Protocol Patterns can be Strategy – Deal with decoupling interface and implementation of classes and Filter characterized as more objects Adapter abstract descriptions of

Behavioral patterns Concurrency frameworks, which are Protocol Pipeline Strategy

Active Object implemented in a particular Framework Framework – Deal with dynamic interactions among societies of classes and Streams Service Configurator language objects

In general, sophisticated frameworks embody dozens of patterns and patterns are often used to document frameworks

Vanderbilt University 16 Vanderbilt University 17

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Creational Patterns Structural Patterns

Factory Method

Adapter – Method in a derived class creates associates – Translator adapts a server interface for a client

Abstract Factory

– Factory for building related objects Bridge – Abstraction for binding one of many implementations Builder

– Factory for building complex objects incrementally Composite

Prototype – Structure for building recursive aggregations

– Factory for cloning new instances from a prototype Decorator

Singleton – Decorator extends an object transparently – Factory for a singular (sole) instance

Vanderbilt University 18 Vanderbilt University 19 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Structural Patterns (cont’d) Behavioral Patterns

Facade Chain of Responsibility – Facade simpliﬁes the interface for a subsystem – Request delegated to the responsible service provider

Flyweight Command – Many fine-grained objects shared efficiently – Request as first-class object

Proxy Interpreter – One object approximates another – Language interpreter for a small grammar

Iterator – Aggregate elements are accessed sequentially

Vanderbilt University 20 Vanderbilt University 21

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Behavioral Patterns (cont’d) Behavioral Patterns (cont’d)

Mediator Strategy – Mediator coordinates interactions between its associates – Abstraction for selecting one of many algorithms

Memento Template Method – Snapshot captures and restores object states privately – Algorithm with some steps supplied by a derived class

Observer Visitor – Dependents update automatically when a subject changes – Operations applied to elements of an heterogeneous object structure

State – Object whose behavior depends on its state

Vanderbilt University 22 Vanderbilt University 23 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt When to Use Patterns What Makes a Pattern a Pattern? 1. Solutions to problems that recur with variations A pattern must:

Solveaproblem, Teach No need for reuse if the problem only arises in one context 2. Solutions that require several steps – i.e.,itmustbeuseful! – It must provide sufﬁcient understanding to tailor the

Have a context , Not all problems need all steps solution

Patterns can be overkill if solution is simple linear set of – It must describe where the

Haveaname instructions solution can be used 3. Solutions where the solver is more interested in the existence of the – It must be referred to Recur, solution than its complete derivation consistently – It must be relevant in other Patterns leave out too much to be useful to someone who really situations wants to understand – They can be a temporary bridge, however

Vanderbilt University 24 Vanderbilt University 25 - OO Patterns Douglas C. Schmidt - HANDLERS HANDLERS VISOR VISOR

Case Study: A Reusable Object-Oriented SUPER SUPER SUPERVISOR SUPERVISOR Communication Software Framework CENTER CENTER

Developing portable, reusable, and efﬁcient communication software : Reactor - : Reactor - MANAGER is hard MANAGER CALL CALL VISOR VISOR SUPER SUPER

OS platforms are often fundamentally incompatible SWITCH SWITCH HANDLERS – e.g., different concurrency and I/O models HANDLERS - - schmidt/PDF/ECOOP- schmidt/PDF/DSEJ-94.pdf

Thus, it may be impractical to directly reuse: NETWORK NETWORK VISOR VISOR SUPER – Algorithms SUPER EVENT EVENT SERVER – Detailed designs SERVER – Interfaces System Overview – Implementations - - ERICSSON VISOR VISOR SUPER SUPER ERICSSON MD110 MD110 ERICSSON 95.pdf OO framework for Call Center Management www.cs.wustl.edu/ www.cs.wustl.edu/ TELECOM TELECOM SWITCHES SWITCHES MD110 MD110 ERICSSON Vanderbilt University 26 OO Patterns Do Vanderbilt University OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Problem: Cross-platform Reuse Solution: Reuse Design Patterns

Protocol Handlers (HTTP) OO framework was ﬁrst developed Publisher Patterns support reuse of on UNIX and later ported to Subscriber software architecture Windows NT 3.51 in 1993

Pipes & Patterns embody Layers Filters WaitForCompletion() UNIX and Windows NT have successful solutions to I/O fundamentally different I/O models Acceptor- Component problems that arise when Subsystem I/O Completion Connector Configurator developing software in a Port – i.e., synchronous vs. particular context STRATEGIC read() write() read()write() read() read() accept() asynchronous Reactor PATTERNS

Patterns reduced project

Thus, direct reuse of original risk by leveraging proven framework was infeasible TACTICAL Factory Wrapper PATTERNS Iterator Composite Method Proxy Facade design expertise – Later solved by ACE and Windows NT 4.0

Vanderbilt University 28 Vanderbilt University 29

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt The Reactor Pattern Collaboration in the Reactor Pattern Reactor select (handles); Intent callback : foreach h in handles loop main Reactor handle_events() Concrete Note inversion of table[h].handle_event(type) register_handler(h) program Event_Handler control end loop Decouples Reactor() remove_handler(h) handlers synchronous event INITIALIZE 1 N Event Handler register_handler(callback) uses REGISTER HANDLER Also note how Handle owns handle_event(type) demuxing & dispatching get_handle() get_handle() EXTRACT HANDLE long-running

from event handling MODE notifies handle_events() event handler START EVENT LOOP

Forces Resolved INITIALIZATION select() callbacks can Synchronous Event Concrete FOREACH EVENT DO Demultiplexer Event handle_input() degrade quality Efﬁciently demux select() Handler DATA ARRIVES of service events synchronously handle_output() OK TO SEND

www.cs.wustl.edu/ schmidt/POSA/ within one thread handle_signal() SIGNAL ARRIVES

MODE handle_timeout() Extending applications TIMER EXPIRES remove_handler(callback) without changing REMOVE HANDLER EVENT HANDLING handle_close() demux infrastructure CLEANUP

Vanderbilt University 30 Vanderbilt University 31 OO Patterns Douglas C. Schmidt Using ACE’s Reactor Pattern Implementation

#include "ace/Reactor.h" class My_Event_Handler : public ACE_Event_Handler { public: virtual int handle_input (ACE_HANDLE h) { cout << "input on handle " << h << endl; return 0; } virtual int handle_signal (int signum, siginfo_t *, ucontext_t *) { cout << "signal " << signum << endl; return 0; }

virtual ACE_HANDLE get_handle (void) const { Implementation (cont’d) return ACE_STDIN; } Using ACE’s Reactor Pattern

}; (&eh, ACE_Event_Handler::READ_MASK); (SIGINT, &eh); reactor.handle_events (); My_Event_Handler eh; ACE_Reactor reactor; reactor.register_handler reactor.register_handler for (;;) /* NOTREACHEDreturn */ 0; int main{ (int argc, char *argv[]) Vanderbilt University Vanderbilt University 32 OO Patterns Do }

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Differences Between UNIX and Windows NT Lessons Learned from Case Study

Reactive vs. Proactive I/O

– Reactive I/O is synchronous Real-world constraints of OS platforms can preclude direct reuse of – Proactive I/O is asynchronous communication software

Requires additional interfaces to “arm” the I/O mechanism – e.g., must often use non-portable features for performance – See Proactor pattern

Reuse of design patterns may be the only viable means to leverage www.cs.wustl.edu/ schmidt/POSA/ previous development expertise

Other differences include

Design patterns are useful, but are no panacea – Resource limitations

e.g., Windows WaitForMultipleObjects() limits – Managing expectations is crucial HANDLEs per-thread to 64 – Deep knowledge of platforms, systems, and protocols is also very – Demultiplexing fairness important

e.g., WaitForMultipleObjects always returns the lowest active HANDLE

Vanderbilt University 34 Vanderbilt University 35 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Key Principles Planning for Change

Successful patterns and frameworks can be boiled down to a few Often, aspects of a design “seem” constant until they are examined key principles: in the light of the dependency structure of an application 1. Separate interface from implementation – At this point, it becomes necessary to refactor the framework or 2. Determine what is common and what is variable with an interface pattern to account for the variation and an implementation

Frameworks often represent the distinction between commonality – Common == stable and variability via template methods and hook methods, respectively 3. Allow substitution of variable implementations via a common interface

Dividing commonality from variability should be goal-oriented rather than exhaustive

Vanderbilt University 36 Vanderbilt University 37

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt The Open/Closed Principle The Open/Closed Principle (cont’d)

Determining common vs. variable components is important Components should be: – Insufficient variation makes it hard for users to customize – open for extension framework components – closed for modification – Conversely, insufficient commonality makes it hard for users to

Impacts comprehend and depend upon the framework’s behavior – Abstraction is good

In general, dependency should always be in the direction of stability – Inheritance and polymorphism are good – i.e., a software component should not depend on any component – Public data members and global data are bad that is less stable than itself – Run-time type identiﬁcation can be bad

The “Open/Closed” principle – This principle allows the most stable component to be extensible

Vanderbilt University 38 Vanderbilt University 39 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Violation of Open/Closed Principle Application of Open/Closed Principle struct Shape { enum Type { CIRCLE, SQUARE } class Shape { shape_type; public: /*...*/}; virtual void draw () const = 0; void draw_square (const Square &); }; void draw_circle (const Circle &); class Square : public Shape { /*...*/}; void draw_shape (const Shape &shape) { class Circle : public Shape { /*...*/}; switch (shape.shape_type) { case SQUARE: typedef vector Shape_Vector; draw_square ((const Square &) shape); break; void draw_all (const Shape_Vector &shapes) { case CIRCLE: for (Shape_Vector::iterator i = shapes.begin(); draw_circle ((const Circle &) shape); i != shapes.end (); break; i++) // etc. (*iterator).draw (); }

Vanderbilt University 40 Vanderbilt University 41

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Beneﬁts of Design Patterns Drawbacks to Design Patterns

Design patterns enable large-scale reuse of software Patterns do not lead to direct code reuse architectures

Patterns are deceptively simple – They also help document systems to enhance understanding

Teams may suffer from pattern overload

Patterns explicitly capture expert knowledge and design

Patterns are validated by experience and discussion rather tradeoffs, and make this expertise more widely available than by automated testing

Patterns help improve developer communication

Integrating patterns into a software development process is a – Pattern names form a vocabulary human-intensive activity

Patterns help ease the transition to object-oriented technology

Vanderbilt University 42 Vanderbilt University 43 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Tips for Using Patterns Effectively Lessons Learned using OO Frameworks

Do not recast everything as a pattern. Beneﬁts of frameworks – Instead, develop strategic domain patterns and reuse existing – Enable direct reuse of code tactical patterns – Facilitate larger amounts of reuse than stand-alone functions or individual classes

Institutionalize rewards for developing patterns

Drawbacks of frameworks

Directly involve pattern authors with application developers and domain experts – High initial learning curve

Many classes, many levels of abstraction

Clearly document when patterns apply and do not apply – The ﬂow of control for reactive dispatching is non-intuitive

Manage expectations carefully – Veriﬁcation and validation of generic components is hard

Vanderbilt University 44 Vanderbilt University 45

OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Patterns and Framework Literature Conferences and Workshops on Patterns

Books

Pattern Language of Programs Conferences – GammaObject-Oriented et al., Design Software Patterns: Elements of Reusable AW, ’94 – September 8-12, 2003, Monticello, Illinois, USA – Pattern Languages of Program Design series by AW, ’95-’99. – http://hillside.net/conferences/plop.htm – Siemens & Schmidt, Pattern-Oriented Software Architecture ,

The European Pattern Languages of Programming conference www.posa.uci.edu Wiley,Complexity volumes with ’96ACE & and ’00 Patterns ( ) – Schmidt & Huston, C++ Network Programming: Mastering – June 25-29, 2003, Kloster Irsee, Germany ,AW,’02 – http://hillside.net/conferences/europlop.htm www.cs.wustl.edu/˜schmidt/ACE/book1/ (Reuse with ACE and Frameworks ) – Schmidt & Huston, C++ Network Programming: Systematic Middleware 2003 ,AW,’03 – June 16-20, 2003, Rio, Brazil (www.cs.wustl.edu/˜schmidt/ACE/book2/) – www.cs.wustl.edu/ schmidt/activities-chair.html

Vanderbilt University 46 Vanderbilt University 47 OO Patterns Douglas C. Schmidt Summary

Mature engineering disciplines have handbooks that describe successful solutions to known problems – e.g., automobile designers don’t design cars using the laws of physics, they adapt adequate solutions from the handbook known to work well enough – The extra few percent of performance available by starting from scratch typically isn’t worth the cost

Patterns can form the basis for the handbook of software engineering – If software is to become an engineering discipline, successful practices must be systematically documented and widely disseminated

Vanderbilt University 48