Using Design Patterns to Develop Object-Oriented Communication ...

Using Design Patterns to Develop Object-Oriented Communication Software Frameworks and Applications Douglas C. Schmidt http://www.cs.wustl.edu/schmidt/ [email protected] Washington University, St. Louis

Motivation 

Developing ecient, robust, extensible, and reusable communication software is hard



It is essential to understand successful techniques that have proven eective to solve common development challenges



Design patterns and frameworks help to capture, articulate, and instantiate these successful techniques

2

1

Observations 

Developers of communication software confront recurring challenges that are largely application-independent {





Design Patterns 

e.g., service initialization and distribution, error handling, ow control, event demultiplexing, concurrency control

Successful developers resolve these challenges by applying appropriate design patterns

{



2. Buried within the source code 3



i.e., \Patterns == problem/solution pairs in a context"

Patterns capture the static and dynamic structure and collaboration among key participants in software designs {

These patterns have traditionally been either: 1. Locked inside the heads of expert software developers

Design patterns represent solutions to problems that arise when developing software within a particular context

They are particularly useful for articulating how and why to resolve non-functional forces

Patterns facilitate reuse of successful software architectures and designs 4

Proxy Pattern More Observations

1: METHOD

: BROKER

CALL

4: METHOD RETURN

: QUOTER PROXY



2: FORWARD

{

REQUEST

3: RESPONSE CLIENT

Reuse of patterns alone is not insucient

: QUOTER

NETWORK

Patterns enable reuse of architecture and design knowledge, but not code (directly)



To be productive, developers must also reuse detailed designs, algorithms, interfaces, implementations, etc.



Application frameworks are an eective way to achieve broad reuse of software

SERVER



Indent: provide a surrogate for another object that controls access to it 5

Frameworks 



Dierences Between Class Libraries and Frameworks

A framework is: {

6

\An integrated collection of components that collaborate to produce a reusable architecture for a family of related applications"

APPLICATION SPECIFIC LOGIC

Frameworks dier from conventional class libraries:

EVENT LOOP

3. Frameworks provide \inversion of control" 

MATH

INVOKES

Typically, applications are developed by inheriting from and instantiating framework components 7

MATH

INVOKES

USER INTERFACE

ADTS DATA BASE

CLASS LIBRARIES

1. Frameworks are \semi-complete" applications 2. Frameworks address a particular application domain

NETWORKING

ADTS

NETWORKING APPLICATION SPECIFIC LOGIC

CALL BACKS

USER INTERFACE

EVENT LOOP

DATABASE

OBJECT-ORIENTED FRAMEWORK 8

Stand-alone vs. Distributed Application Architectures

Tutorial Outline 



Outline key challenges for developing communication software

COMPUTER

FILE SYSTEM

CD ROM

Present the key reusable design patterns in an application-level Gateway {



PRINTER

(1) STAND-ALONE APPLICATION ARCHITECTURE DISPLAY SERVICE

Both single-threaded and multi-threaded solutions are presented

CYCLE SERVICES FI LE SERVICE

PRINT SERVICE

Discuss lessons learned from using patterns on production software systems

NETWORK

PRINTER

CD ROM

FILE SYSTEM

(2) DISTRIBUTED APPLICATION ARCHITECTURE

9

10

Sources of Complexity

Concurrency vs. Parallelism SERVER



Distributed application development exhibits both inherent and accidental complexity



Inherent complexity results from fundamental challenges, e.g.,

maxfdp1 read_fds

CLIENT

WORK REQUEST

CLIENT

WORK REQUEST

WORK REQUEST CLIENT

WORK

{

REQUEST CLIENT

CONCURRENT SERVER SERVER

CPU1

CPU2

CPU3

CPU4

{

CLIENT

WORK REQUEST

CLIENT

WORK REQUEST

WORK REQUEST CLIENT

WORK REQUEST

Distributed systems . Latency .

Error handling

.

Service partitioning and load balancing

Concurrent systems . Race conditions .

Deadlock avoidance

.

Fair scheduling

.

Performance optimization and tuning

CLIENT

PARALLEL SERVER 11

12

OO Contributions 

Sources of Complexity (cont'd) 

{

Accidental complexity results from limitations with tools and techniques, e.g., {

{ {

Lack of type-secure, portable, re-entrant, and extensible system call interfaces and component libraries

{

Inadequate debugging support

{

Widespread use of algorithmic decomposition .

Fine for explaining network programming concepts and algorithms but inadequate for developing large-scale distributed applications

Concurrent and distributed programming has traditionally been performed using low-level OS mechanisms, e.g.,

{ { 

fork/exec Shared memory Signals Sockets and select POSIX pthreads, Solaris threads, Win32 threads

OO design patterns and frameworks elevate development to focus on application concerns, e.g.,

Service functionality and policies { Service con guration { Concurrent event demultiplexing and event handler dispatching { Service concurrency and synchronization {

14

13

Physical Architecture of the Gateway

Application-level Gateway Example 





SATELLITES TRACKING STATION PEERS

This example illustrates the reusable design patterns and framework components used in an OO architecture for application-level Gateways Gateways route messages between Peers in a distributed system

STATUS INFO

WIDE AREA NETWORK

e.g., TCP/IP, IPX/SPX, TP4

GATEWAY

GROUND STATION PEERS 15

TRANSFER COMMANDS

Peers and Gateways communicate via a connectionoriented transport protocol {

BULK DATA

LOCAL AREA NETWORK

16

Graphical Notation

OO Software Architecture of the Gateway : Output Channel

OBJECT

: CLASS

PROCESS

: Routing Table

THREAD

: Input Channel

: Reactor

: Input Channel

: Channel Acceptor

: Channel Connector

GATEWAY

INCOMING MESSAGES CONNECTION REQUEST PEER1

PEER2

CONNECTION REQUEST

PEER3

CLASS

: Output Channel

CLASS CATEGORY

OUTGOING MESSAGES

INHERITS

ABSTRACT CLASS

PEER4

CLASS UTILITY

TEMPLATE CLASS

INSTANTIATES

CONTAINS

A

USES

17

18

Gateway Behavior 

Design Patterns in the Gateway

Components in the Gateway behave as follows: 1.

Gateway parses con guration les that specify which

2.

Channel Connector

Active Object

Router

Peers to connect with and which routes to use

Connector

connects to Peers, then creates and activates the appropriate Channel subclasses (Input Channel or Output Channel)

3. Once connected, Peers send messages to the Gateway { Messages are handled by the appropriate Input Channel

Half-Sync/ Half-Async STRATEGIC PATTERNS TACTICAL PATTERNS

work as follows: (a) Receive and validate messages

{

Input Channels

(b) Consult a Routing Table



(c) Forward messages to the appropriate Peer(s) via Output Channels 19

Acceptor Service Configurator Reactor

Iterator

Template Method

Factory Method

Adapter

The Gateway components are based upon a family of design patterns 20

Tactical Patterns 

{



\Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation"



\De ne an interface for creating an object, but let subclasses decide which class to instantiate" .

{





\Convert the interface of a class into another interface client expects" .

\Decouples event demultiplexing and event handler dispatching from application services performed in response to events"

Active Object {

Factory Method lets a class defer instantiation to subclasses

Adapter

Reactor {

Factory Method {



Concurrency Patterns

Iterator

\Decouples method execution from method invocation and simpli es synchronized access to shared resources by concurrent threads"

Half-Sync/Half-Async {

Adapter lets classes work together that couldn't otherwise because of incompatible interfaces

\Decouples synchronous I/O from asynchronous I/O in a system to simplify concurrent programming eort without degrading execution eciency"

21

22

Service Initialization Patterns 

Connector {



Acceptor {



\Decouples active connection establishment from the service performed once the connection is established"

Application-Speci c Patterns 

\Decouples passive connection establishment from the service performed once the connection is established"

Router {

\Decouples multiple sources of input from multiple sources of output to route data correctly without blocking"

Service Con gurator {

\Decouples the behavior of network services from point in time at which services are con gured into an application"

23

24

The ADAPTIVE Communication Environment (ACE) DISTRIBUTED SERVICES

GATEWAY SERVER

FRAMEWORKS AND CLASS CATEGORIES

TOKEN SERVER

ACCEPTOR

LOGGING SERVER

CONNECTOR

SERVICE HANDLER

ACE Components in the Gateway : Output Channel

: Reactor

SYNCH WRAPPERS

C APIS

THREAD LIBRARY

LOG MSG SPIPE SAP

STREAM PIPES

PROCESS/THREAD SUBSYSTEM

SOCK_SAP/ TLI_SAP SOCKETS/

TLI

SERVICE CONFIGURATOR

SHARED MALLOC

FIFO SAP NAMED PIPES

MEM MAP SELECT/ POLL

COMMUNICATION SUBSYSTEM

GENERAL



REACTOR

UNIX

AND

DYNAMIC LINKING

MEMORY MAPPING

: Connector

: SOCK Stream

SYSV

: SOCK Connector

: Acceptor

: Map Manager

: SOCK Stream

: SOCK Acceptor

SYSTEM

V IPC

GATEWAY

INCOMING MESSAGES

CONNECTION REQUEST

SERVICES

A set of C++ wrappers and frameworks based on common design patterns

OUTGOING MESSAGES CONNECTION REQUEST

PEERS

PEERS

25

Intent {

26

Structure of the Reactor Pattern

The Reactor Pattern 

\Decouples event demultiplexing and event handler dispatching from the services performed in response to events"

select (handles); foreach h in handles { if (h is output handler) table[h]->handle_output () ; if (h is input handler) table[h]->handle_input (); if (h is signal handler) table[h]->handle_signal (); } this->expire_timers ();

Concrete Event_Handler

{

{

How to demultiplex multiple types of events from multiple sources of events eciently within a single thread of control

handle_input() handle_output() handle_signal() handle_timeout() get_handle() A

This pattern resolves the following forces for event-driven software:

1

Reactor

handle_events() register_handler(h) remove_handler(h) expire_timers()

1

1

AP PL DE ICA T PE ND IONEN T

Event_Handler

n



: Message Queue

WRAPPERS

VIRTUAL MEMORY SUBSYSTEM

WIN32

: Output Channel

: Input Channel

(ASX)

WRAPPERS

: Input Channel

: Routing Table

: SOCK Stream

CORBA HANDLER

ADAPTIVE SERVICE EXECUTIVE

THREAD MANAGER

C++

: Message Queue

: SOCK Stream

NAME SERVER

: Map Manager

n

AP P IN LICA DE PE TION ND EN T

n

1

1 1

Timer_Queue schedule_timer(h) cancel_timer(h) expire_timer(h)

Handles 1

n

How to extend application behavior without requiring changes to the event dispatching framework 

27

Participants in the Reactor pattern 28

EXTRACT HANDLE START EVENT LOOP FOREACH EVENT DO DATA ARRIVES OK TO SEND SIGNAL ARRIVES TIMER EXPIRES REMOVE HANDLER CLEANUP

register_handler(callback) get_handle()

APPLICATION LEVEL

REGISTER HANDLER

REGISTERED OBJECTS

: Output Channel

: Output Channel 4: send(msg)

: Event Handler

: Event Handler

2: recv(msg) 3: route(msg)

handle_events() select() handle_input() handle_output()

FRAMEWORK LEVEL

MODE

INITIALIZE

callback : reactor Concrete : Reactor Event_Handler Reactor()

Using the Reactor for the Gateway

remove_handler(callback) handle_close()

: Handle Table

:Timer Queue

: Event Handler

: Signal Handlers

: Reactor

handle_signal() handle_timeout()

: Input Channel

1: handle_input()

OS EVENT DEMULTIPLEXING INTERFACE

KERNEL LEVEL

main program

MODE

EVENT HANDLING

INITIALIZATION

Collaboration in the Reactor Pattern

29

30

Structure of the Router Pattern

The Router Pattern {

The Router pattern resolves the following forces for connection-oriented routers: {

{

How to prevent misbehaving connections from disrupting the quality of service for well-behaved connections

find()

Input Channel recv_msg()

I/O



\Decouple multiple sources of input from multiple sources of output to route data correctly without blocking"

ROUTING LAYER

Intent

LAYER



Routing Table

1

Message Queue

n Output Channel send_msg() put()

EVENT SOURCE AND SINK

How to allow dierent concurrency strategies for Input and Output Channels 

31

Participants in the Router pattern 32

Structure of the Single-Threaded Router Pattern

: Output Channel

: Input Channel

ROUTE SELECTION PHASE

I/O Layer

recv_msg()

RECV MSG ROUTE MSG

OUTPUT PROCESSING PHASE

: Routing Table

find ()

FIND DESTINATIONS SEND MSG (QUEUE IF FLOW CONTROLLED)

put()

send_msg() enqueue()

Input Channel handle_input()

handle_output() put()

wakeup()

send_msg()

Event Handler

33

: Output Channel

: Routing Table

: Message Queue

4: pu t( m sg )

Subscriber Set

7: put (msg)

1: handle_input() 2: recv_peer(msg)



8: send_peer(msg) 9: enqueue(msg) 10: schedule_wakeup() --------------11: handle_output() 12: dequeue(msg) 13: send_peer(msg)

35

Reactor

Intent {

5: send_peer(msg)

: Message Queue

1

The Active Object Pattern 

: Output Channel

n

34

Collaboration in Single-threaded Gateway Routing

: Input Channel

Message Queue

dequeue()

DEQUEUE AND SEND MSG (REQUEUE IF FLOW CONTROLLED)

3: find()

n Output Channel

schedule_wakeup()

FLOW CONTROL ABATES

ROUTE ID

1

find()

ROUTING LAYER

main()

Routing Table

REACTIVE LAYER

INPUT PROCESSING PHASE

Collaboration in the Router Pattern

\Decouples method execution from method invocation and simpli es synchronized access to shared resources by concurrent threads"

This pattern resolves the following forces for concurrent communication software: {

How to allow blocking read and write operations on one endpoint that do not detract from the quality of service of other endpoints

{

How to simplify concurrent access to shared state

36

Structure of the Active Object Pattern Client Interface

INVISIBLE TO CLIENTS

insert() remove() 1

n

1

Resource Representation

Method Objects

CONSTRUCTION

1

1

METHOD OBJECT

1

Activation Queue

EXECUTION

dispatch() m1'() m2'() m3'()

client

SCHEDULING/

VISIBLE TO CLIENTS

Scheduler

COMPLETION

ResultHandle m1() ResultHandle m2() ResultHandle m3()

Collaboration in the Active Object Pattern

loop { m = actQueue.remove() dispatch (m) }

: Client : Activation : Represent: Scheduler Interface Queue ation

m1()

INVOKE CREATE METHOD OBJECT RETURN RESULT HANDLE

cons(m1') future()

INSERT IN PRIORITY QUEUE

insert(m1') remove(m1')

DEQUEUE NEXT METHOD OBJECT

dispatch(m1')

EXECUTE RETURN RESULT

reply_to_future()

The Scheduler is a \meta-object" that determines the sequence Method Objects are executed



37

KERNEL LEVEL

FRAMEWORK LEVEL

APPLICATION LEVEL

Using the Active Object Pattern for the Gateway : Output Channel : Event Handler

REGISTERED : Input : Output OBJECTS : Input Channel Channel : Input Channel Channel 4: send(msg) : Event : Event : Event Handler : Event Handler Handler 2: recv(msg) Handler 3: route(msg) 1: handle_input()

:Timer Queue

: Handle Table

: Reactor

38

Collaboration in the Active Object-based Gateway Routing : Output Channel

: Routing Table

ROUTE ID

3: find()

ACTIVE

Subscriber Set

4: put (msg)

: Signal Handlers

: Input Channel

OS EVENT DEMULTIPLEXING INTERFACE

5: send_peer(msg)

: Message Queue

: Output Channel : Message Queue ACTIVE

1: handle_input () 2: recv_peer(msg)

39

5: send_peer(msg)

40

{



\Decouples synchronous I/O from asynchronous I/O in a system to simplify programming eort without degrading execution eciency"

This pattern resolves the following forces for concurrent communication systems: {

How to simplify programming for higher-level communication tasks .

{

These are performed synchronously

How to ensure ecient lower-level I/O communication tasks .

These are performed asynchronously

SYNCHRONOUS TASK LAYER

Intent

QUEUEING LAYER



ASYNCHRONOUS TASK LAYER

Half-Sync/Half-Async Pattern

Structure of the Half-Sync/Half-Async Pattern SYNC

SYNC

TASK 3

TASK 1

SYNC TASK 2

1, 4: read(data) MESSAGE QUEUES

3: enqueue(data) ASYNC TASK

2: interrupt EXTERNAL EVENT SOURCES

41

42

EXTERNAL EVENT RECV MSG

PHASE PHASE

SYNC QUEUEING

PROCESS MSG



ENQUEUE MSG

Async Task

Message Queue

Sync Task

notification() read(msg) work() enqueue(msg) read(msg)

DEQUEUE MSG EXECUTE TASK

work()

This illustrates input processing (output processing is similar) 43

QUEUEING SYNCHRONOUS LAYER TASK LAYER

ASYNC

PHASE

External Event Source

ASYNCHRONOUS TASK LAYER

Collaborations in the Half-Sync/Half-Async Pattern

Using the Half-Sync/Half-Async Pattern in the Gateway : Output Channel

: Output Channel

: Output Channel

1: dequeue(msg) 2: send(msg)

MESSAGE QUEUES

2: recv(msg) 3: get_route(msg) 4: enqueue(msg) : Input : Input Channel : Input Channel Channel

1: dispatch() : Reactor

44

Structure of the Connector Pattern

\Decouples active initialization of a service from the task performed once a service is initialized"

This pattern resolves the following forces for network clients that use interfaces like sockets or TLI:



1. How to reuse active connection establishment code for each new service 2. How to make the connection establishment code portable across platforms that may contain sockets but not TLI, or vice versa 3. How to enable exible service concurrency policies 4. How to actively establish connections with large number of peers eciently

SOCK Stream n Concrete Svc Handler

1

open()

S INIT

SVC_HANDLER PEER_CONNECTOR

Connector

connect_svc_handler() activate_svc_handler() handle_output() connect(sh, addr)

PEER_STREAM

Svc Handlern open()

Concrete_Svc_Handler SOCK_Connector

Concrete Connector

A

CONNECTION LAYER

{

A

1: 2:

REACTIVE LAYER

Intent



APPLICATION LAYER

The Connector Pattern

Event Handler handle_output()

connect_svc_handler (sh, addr);

activate_svc_handler (sh);

1

n

Reactor

46

45

Collaboration in the Connector Pattern



sh: Svc_Handler

reactor : Reactor

connect(sh, addr) connect_svc_handler(sh, addr)

INITIATE CONNECTION SYNC CONNECT

connect() activate_svc_handler(sh)

ACTIVATE OBJECT

open() INSERT IN REACTOR EXTRACT HANDLE START EVENT LOOP FOREACH EVENT DO DATA ARRIVES PROCESS DATA

register_handler(sh) get_handle() handle_events() select() handle_input() svc()

CONNECTION INITIATION PHASE

FOREACH CONNECTION

con : : SOCK Connector Connector

SERVICE INITIALIZATION PHASE

Client

Client

SERVICE PROCESSING PHASE

SERVICE PROCESSING PHASE

CONNECTION INITIATION/ SEVICE INITIALIZATION PHASE

Collaboration in the Connector Pattern

FOREACH CONNECTION

con : : SOCK Connector Connector

sh: Svc_Handler

reactor : Reactor

connect(sh, addr) connect_svc_handler(sh, addr)

INITIATE CONNECTION ASYNC CONNECT

connect()

INSERT IN REACTOR

handle_events()

START EVENT LOOP

select()

FOREACH EVENT DO

handle_event() activate_svc_handler(sh)

CONNECTION COMPLETE ACTIVATE OBJECT INSERT IN REACTOR EXTRACT HANDLE

DATA ARRIVES PROCESS DATA

register_handler(con)

open()

register_handler(sh) get_handle() handle_input() svc()

Synchronous mode  47

Asynchronous mode 48

The Acceptor Pattern Using the Connector for the Gateway : Channel : Channel : Channel : Svc : Svc Handler : Svc Handler Handler

: Channel

: Channel : Channel

: Svc Handler

: Svc Handler

PENDING

\Decouples passive initialization of a service from the tasks performed once the service is initialized"

This pattern resolves the following forces for network servers using interfaces like sockets or TLI:



1. How to reuse passive connection establishment code for each new service : Channel

CONNECTIONS

: Svc Handler

: Reactor

CONNECTIONS

{

: Svc Handler

ACTIVE

: Connector

Intent



2. How to make the connection establishment code portable across platforms that may contain sockets but not TLI, or vice versa 3. How to ensure that a passive-mode descriptor is not accidentally used to read or write data 4. How to enable exible policies for creation, connection establishent, and concurrency

49

50

Collaboration in the Acceptor Pattern

Svc Handler

S INIT

open() A

Concrete_Svc_Handler SOCK_Acceptor

Concrete Acceptor

open()

PEER_STREAM

CONNECTION LAYER

1

A

SVC_HANDLER PEER_ACCEPTOR

Acceptor make_svc_handler() accept_svc_handler() activate_svc_handler() open() handle_input()

REACTIVE LAYER

sh = make_svc_handler(); accept_svc_handler (sh); activate_svc_handler (sh);

Event Handler

handle_input()

n

1

acc : : SOCK Acceptor Acceptor open() open()

Server

SERVICE ENDPOINT INITIALIZATION INITIALIZATION PHASE PHASE

SOCK Stream n Concrete Svc Handler

SERVICE PROCESSING PHASE

APPLICATION LAYER

Structure of the Acceptor Pattern

INITIALIZE PASSIVE ENDPOINT REGISTER HANDLER EXTRACT HANDLE START EVENT LOOP FOREACH EVENT DO CONNECTION EVENT CREATE, ACCEPT, AND ACTIVATE OBJECT REGISTER HANDLER FOR CLIENT I/O EXTRACT HANDLE DATA EVENT PROCESS MSG CLIENT SHUTDOWN SERVER SHUTDOWN

sh: Svc_Handler

reactor : Reactor

register_handler(acc) get_handle() handle_events() select() handle_input() sh = make_svc_handler() accept_svc_handler (sh) activate_svc_handler (sh) register_handler(sh) get_handle() handle_input() svc() handle_close() handle_close()

Reactor

is a factory that creates, connects, and activates a Svc Handler

 Acceptor 51

52

Using the Acceptor Pattern in the Gateway

The Service Con gurator Pattern 

Intent {

: Input Acceptor

: Output Acceptor

: Input Channel

: Output Channel

: Svc Handler

: Svc Handler

: Output Channel : Svc Handler

ACTIVE CONNECTIONS

PASSIVE LISTENERS



This pattern resolves the following forces for highly exible communication software: {

: Input Channel

: Reactor

\Decouples the behavior of network services from the point in time at which these services are con gured into an application"

How to defer the selection of a particular type, or a particular implementation, of a service until very late in the design cycle .

: Svc Handler

i.e., at installation-time or run-time

{

How to build complete applications by composing multiple independently developed services

{

How to recon gure and control the behavior of the service at run-time 54

53

APPLICATION LAYER

Structure of the Service Con gurator Pattern

Collaboration in the Service Con gurator Pattern

Concrete Service Object

main()

suspend() resume() init() A fini() info()

1 1 1

n 1

Event Handler n

FOREACH SVC ENTRY DO DYNAMICALLY LINK SERVICE INITIALIZE SERVICE REGISTER SERVICE EXTRACT HANDLE

: Reactor

: Service : Service Config Repository

Service_Config() process_directives() link_service() init(argc, argv) register_handler(svc) get_handle() insert()

STORE IN REPOSITORY START EVENT LOOP

Service Repository

1

CONFIGURATION MODE

Service Config

Service Object

EVENT HANDLING MODE

REACTIVE LAYER

CONFIGURATION LAYER

CONFIGURE

svc : Service_Object

FOREACH EVENT DO INCOMING EVENT SHUTDOWN EVENT CLOSE SERVICE UNLINK SERVICE

run_event_loop() handle_events() handle_input() handle_close() remove_handler(svc) fini()

unlink_service()

remove()

Reactor

55

56

Using the Service Con gurator Pattern for the Gateway : Thread Gateway

SERVICE CONFIGURATOR RUNTIME

: Service Repository : Service Config



: Reactive Gateway : Service Object

SHARED

: Service Object

OBJECTS

Bene ts of Design Patterns 

Design patterns enable large-scale reuse of software architectures



Patterns explicitly capture expert knowledge and design tradeos



Patterns help improve developer communication



Patterns help ease the transition to objectoriented technology

: Thread Pool Gateway : Reactor

: Service Object

Replace the single-threaded Gateway with a multi-threaded Gateway 57

58

Suggestions for Using Patterns Eectively

Drawbacks to Design Patterns 

Patterns do not lead to direct code reuse



Patterns are deceptively simple



Teams may suer from pattern overload



Patterns are validated by experience rather than by testing



Integrating patterns into a software development process is a human-intensive activity 59



Do not recast everything as a pattern {

Instead, develop strategic domain patterns and reuse existing tactical patterns



Institutionalize rewards for developing patterns



Directly involve pattern authors with application developers and domain experts



Clearly document when patterns apply and do not apply



Manage expectations carefully 60

Books and Magazines on Patterns 

Books { {





Gamma et al., \Design Patterns: Elements of Reusable Object-Oriented Software" Addison-Wesley, Reading, MA, 1994. \Pattern Languages of Program Design," editors James O. Coplien and Douglas C. Schmidt, AddisonWesley, Reading, MA, 1995

{

\Theory and Practice of Object Systems" (guest editor: Stephen P. Berczuk)

{

\Communications of the ACM" (guest editors: Douglas C. Schmidt, Ralph Johnson, and Mohamed Fayad)

Magazines C++ Report and Journal of Object-Oriented Programming, columns by Coplien, Vlissides, and De Souza

Obtaining ACE 

The ADAPTIVE Communication Environment (ACE) is an OO toolkit designed according to key network programming patterns



All source code for ACE is freely available {

Anonymously ftp to wuarchive.wustl.edu

{

Transfer the les /languages/c++/ACE/*.gz and gnu/ACE-documentation/*.gz

Mailing lists * [email protected] * [email protected] * [email protected] * [email protected]

WWW URL {

Joint Pattern Languages of Programs Conferences {

http://www.cs.wustl.edu/~schmidt/ 63

3rd PLoP .

{

61





Special Issues in Journals

{



Conferences and Workshops on Patterns

1st EuroPLoP .

{ 

September 4,6, 1996, Monticello, Illinois, USA July 10,14, 1996, Kloster Irsee, Germany

http://www.cs.wustl.edu/~schmidt/jointPLoP,96.html/

USENIX COOTS {

June 17,21, 1996, Toronto, Canada

{

http://www.cs.wustl.edu/~schmidt/COOTS,96.html/ 62