experiences Douglas C. Schmidt

Using Design Object Technology Patterns to Develop Reusable Object-Oriented Communication Software

Despite dramatic increases in network and host per- [7] are a promising technique for formance, it remains difficult to design, implement, achieving widespread reuse of software architectures. and reuse communication software for complex dis- Design patterns capture the static and dynamic struc- tributed systems. Examples of these systems include tures and collaborations of components in successful global personal communication systems, network man- solutions to problems that arise when building soft- agement platforms, enterprise medical imaging sys- ware in domains like business data processing, tems, and real-time market data monitoring and telecommunications, graphical user interfaces, data- analysis systems. In addition, it is often hard to directly bases, and distributed communication software. Pat- reuse existing algorithms, detailed designs, interfaces, terns aid the development of reusable components or implementations in these systems due to the growing and frameworks by expressing the structure and col- heterogeneity of hardware/software architectures and laboration of participants in a software architecture the increasing diversity of operating system platforms. at a level higher than source code or object-oriented

COMMUNICATIONS OF THE ACM October 1995/Vol. 38, No. 10 65 design models that focus on individual objects and user interface events generated by Motif. These events classes. Thus, patterns facilitate reuse of software arrive on multiple I/O handles that identify resources architecture, even when other forms of reuse are (such as network connections) managed by an oper- infeasible (e.g., due to fundamental differences in ating system. Input events from peers may arrive operating system features [16]). simultaneously on multiple handles. Therefore, sin- This article describes how design patterns are gle-threaded software must not block indefinitely being applied on a number of large-scale commercial reading from any individual I/O handle. Blocking can distributed systems. Patterns have been used on these significantly delay the response time for handling projects to enable widespread reuse of communica- events from peers associated with other handles. tion software architectures, developer expertise, and object-oriented framework components. These sys- ne way to develop this type of tems include the Motorola Iridium global personal event-driven software is to use communications system [13], a family of network multi-threading. In this monitoring applications for Ericsson telecommunica- approach, a separate is tion switches [16], and a system for transporting mul- spawned for every connected timegabyte medical images over high-speed ATM peer. Each thread blocks on a networks [1] being developed at Washington Univer- read system call. A thread sity School of Medicine in conjunction with Kodak. unblocks when it receives an This article also presents ways to avoid common traps event from its associated peer. At this point, the event and pitfalls of applying design patterns in large-scale is processed within the thread. The thread then O read software development processes. reblocks, awaiting subsequent input from . There are several drawbacks to using multi-thread- Example Design Pattern: The Reactor ing for handling events in communication software: The Reactor pattern was identified while developing reusable event-driven communication software at • Threading may require complex concurrency con- Ericsson, Motorola, and Kodak. Portions of the mate- trol schemes. rial appearing in this article were culled from docu- • Threading may lead to poor performance due to mentation used on these projects. context switching, synchronization, and data Design patterns have been described using several movement. formats [3, 5, 7]. The format used in this article is • Threading may not be available on all operating based on the work of Gamma et al. [7]; it contains the system (OS) platforms. following parts: Often, a more convenient and portable way to devel- • The intent of the pattern op event-driven servers is to use the Reactor pattern. The • The design forces that motivate the pattern Reactor pattern manages a single-threaded event loop • The solution to these forces that performs event demultiplexing and event handler • The structure and roles of classes in the solution dispatching in response to events from multiple • The responsibilities and collaborations among sources. The Reactor pattern combines the simplicity classes and efficiency of single-threaded event loops with the • Implementation guidance extensibility offered by object-oriented programming. • Example source code1 • References to related patterns Applicability Use the Reactor pattern when: Intent The Reactor pattern dispatches handlers automatically • One or more events may arrive concurrently from when events occur from multiple sources. This pattern multiple sources, and blocking or continuously simplifies event-driven applications by decoupling event polling for events on any individual source of demultiplexing and event handler dispatching from events is inefficient; application services performed in response to events. • Each individual event handler possesses the follow- ing characteristics: Motivation — it exchanges fixed-sized or bounded-sized mes- Communication software must respond to events gen- sages with its peers without requiring blocking I/O; erated from multiple sources. For example, network — it processes each message it receives within a management applications for monitoring and con- relatively short period of time; trolling space vehicles in global personal communica- • Using multi-threading to implement event demul- tion systems may receive traps sent by HP OpenView tiplexing is either: agents, telemetry data sent via CORBA requests, and — infeasible due to lack of multi-threading support on an OS platform; 1 Due to space limitations, the sample code has been omitted from this arti- — undesirable due to poor performance on uni- cle. See [14] for a complete example of the Reactor pattern. processors or due to the need for overly complex

66 October 1995/Vol. 38, No. 10 COMMUNICATIONS OF THE ACM experiences

concurrency control schemes; systems, and transaction managers) communicate — redundant due to the use of multi-threading at with the Reactor via Handles. higher levels of an application’s architecture. • Developers subclass Event Handlers to imple- ment application-specific event processing. When Structure an Event Handlers subclass object is registered The structure of the Reactor pattern is illustrated in the with the Reactor, the application indicates the Booch [2] class diagram shown in Figure 1. In Booch type of event(s) (e.g., input event, output event, notation dashed clouds indicate classes, an inscribed signal event) this Event Handlers wants the Reactor

“A’’ indicates an abstract class, directed edges indicate to notify it about. Object Technology inheritance relationships between classes, and an undi- • To bind the Reactor with Handles, a subclass rected edge with a small bullet at one end indicates a of Event Handlers must override the composition relation between two classes. get_handle method. Hence, when an Event Handlers subclass object is registered with the Participants Reactor, the object’s Handle is obtained by The participants in the Reactor pattern include the invoking the Event Handler::get_handle following: method. The Reactor then combines this Han- dle with other registered Event Handlers and • Handles, which identify resources (such as net- waits for events to occur on the Handles. work connections, open files, and synchronization • The Reactor triggers Event Handlers meth- objects) that are managed by an operating system. ods in response to events on the Handlers it • Reactor, which defines an interface for registering, monitors. When events occur, the Reactor uses removing, and dispatching Event Handler the Handles activated by the events as keys to objects. An implementation of the Reactor locate and dispatch the appropriate Event Han- interface provides a set of application-independent dlers methods. This collaboration is structured event demultiplexing and dispatching mecha- using the method callbacks depicted in the object- nisms. These mechanisms dispatch application-spe- interaction diagram shown in Figure 2. cific Event Handlers in response to events • The handle_event method is called by the Reac- occurring on one or more Handles. tor to perform application-specific functionality in • Event Handler, which specifies an interface used response to an event. The type of the event that by the Reactor to dispatch callback methods occurred is passed as a parameter to the method. defined by objects that are pre-registered to han- dle certain types of events (such as input events, Consequences output events, and signals). The Reactor pattern has the following benefits: • Concrete Event Handler, which implements the customized callback method(s) that process events • It improves the modularity, reusability, and config- in an application-specific manner. urability of event-driven application software by decoupling application-independent mechanisms Collaborations Among Participants from application-specific processing policies. • Sources of events (such as network adaptors, file • It improves application portability by allowing its

select (handles) Figure 1. foreach h in handles loop Concrete The structure h->handle_event (event_type) Event Handler of the Reactor end loop pattern

1 Reactor n dispatch() Event Handler register_handler(h, type) handle_event(type) remove_handler(h, type) get_handle() A 1

n Handles

COMMUNICATIONS OF THE ACM October 1995/Vol. 38, No. 10 67 callback: main Concrete reactor: program Event_Handler Reactor : Handles

Reactor() INITIALIZE register_handler(callback) REGISTER HANDLER get_handler() EXTRACT HANDLE dispatch() RUN EVENT LOOP select() WAIT FOR EVENTS handle_event(event_type) DISPATCH HANDLER(S)

interface to be reused inde- Bellcore and Siemens Q.port ATM signaling soft- Figure 2. pendently of the underlying ware product, the Ericsson EOS family of telecom- Object interac- OS system calls that perform munication switch management applications [16], tion diagram event demultiplexing. the network management portion of the Motorola • It provides applications with Iridium global personal communications system coarse-grained concurrency [13] and an enterprise medical image delivery sys- control that serializes the tem for Kodak and Washington University School invocation of Event Handlers and minimizes the of Medicine [1]. need for more complicated synchronization or locking within an application process. Related Patterns The Reactor pattern may be viewed as a variation on The Reactor pattern has the following drawbacks: the [7]. In the Observer pattern, subscribers are updated automatically when a single • Event Handlers are not preempted while they are subject changes. In the Reactor pattern, handlers are executing. Therefore, a handler should not per- informed automatically when events from multiple form blocking I/O on a handle since, this will sig- sources occur. nificantly decrease the responsiveness to clients A Reactor provides a Facade [7] for event de- connected to other I/O handles. Therefore, for multiplexing. A Facade is an interface that shields long-duration operations (such as transferring a applications from complex object relationships with- multimegabyte medical image), the in a subsystem. pattern [9] (which uses multi-threading or multi- The virtual methods provided by the Event Han- processing) may be more effective. dler base class are Template Methods [7]. These • Applications written using the Reactor pattern can be template methods are used by the Reactor to trig- hard to debug because their flow of control oscillates ger callbacks to the appropriate application-specific between the lower-level demultiplexing code (sup- processing functions in response to events. plied by the framework) and the higher-level method The Active Object pattern [9] decouples method callbacks (supplied by application developers). execution from method invocation in order to sim- plify synchronized access to a shared resource by Known Uses methods invoked in different threads of control. This The Reactor pattern has been used in many object- pattern is often used in place of (or in conjunction oriented frameworks and event-driven applications: with) the Reactor pattern when Event Handlers per- form long-duration activities. Likewise, the Reactor • The X-Windows toolkit uses a version of the Reac- pattern can be used in place of (or in conjunction tor pattern to structure its main event loop. This with) the Active Object pattern when threads are not implementation registers and dispatches function available or when the overhead and complexity of calls, rather than objects. managing large numbers of threads is undesirable. • The InterViews window system distribution [10] implements the Reactor pattern in its Dispatcher Lessons Learned class category. The Dispatcher is used to define This section describes lessons learned from develop- an application’s main event loop and to manage ing object-oriented communication frameworks connections to one or more physical GUI displays. based on design patterns at Motorola Iridium [12, • The ADAPTIVE Service eXecutive (ASX) frame- 13], Ericsson [16], and Kodak Health Imaging Sys- work [14] uses the Reactor pattern as the central tems [1]. These large-scale distributed system pro- event demultiplexer/dispatcher in an object-ori- jects have identified, documented, and applied ented toolkit for experimenting with high-perfor- dozens of new or existing design patterns. Patterns mance parallel communication protocol stacks. were used to leverage prior development expertise, as • The Reactor pattern has been used in a number of well as to reduce risk by reusing software architec- commercial products. These products include the tures across diverse OS platforms and subsystems.

68 October 1995/Vol. 38, No. 10 COMMUNICATIONS OF THE ACM experiences

The Motorola Iridium and Ericsson projects were ments and requirements. Although patterns are among the first large-scale distributed system projects inherently abstractions, however, patterns should not to adopt a software reuse strategy based on the con- be described too abstractly. We found that many cepts, notations, and techniques of design patterns. developers had a hard time understanding precisely Patterns identified and applied in these projects have how to implement patterns when they were described been described in [12–16]. These projects have clari- using only object diagrams and structured prose. fied many of the benefits and drawbacks of using To overcome this problem, we provided source code design patterns to systematically capture and articu- examples with our pattern descriptions that gave con-

late communication software architectures. crete guidance for implementing the patterns. When- Object Technology ever possible, we presented multiple implementations his section discusses the lessons of each pattern to help developers overcome the “tun- learned and outlines workarounds nel vision” that can result from a limited pattern vocab- for problems we encountered ulary. Many examples used in our pattern descriptions using design pattern-based reuse came directly from communication frameworks we strategies in production software built for the projects. This helped developers grasp the environments. Our experiences key points of each pattern because they already under- using patterns on the Ericsson, stood the forces and requirements that motivated the Motorola, and Kodak projects pattern. In addition, this approach helped convince were quite similar. Recognizing these common management to support the use of patterns because it Tthemes across different projects increased our confi- reinforced our claim that design patterns had direct dence that these experiences can be generalized to relevance to their projects. using patterns on other large-scale software systems. Patterns improve communication within and across Patterns enable widespread reuse of software architecture software development teams because they provide devel- even if reuse of algorithms, implementations, inter- opers with shared vocabulary and concepts. Patterns faces, or detailed designs is not feasible. The constraints capture essential properties of software architecture, of the underlying OS and hardware platform signifi- while suppressing details that are not relevant at a cantly affect design and implementation decisions. This given level of abstraction. Thus, they provide a com- is particularly problematic for communication soft- prehensible way of documenting complex software ware, where nonportable OS features are often used to architectures by expressing the structure and collab- enhance performance and functionality. The Ericsson oration of participants at a level higher than (1) telecommunication switch management project [16] source code or (2) object-oriented design models illustrated the importance of pattern-based architectur- that focus on individual objects and classes. al reuse. This project underwent several major changes We found that patterns helped to elevate the level over three years. The original prototype was developed of discourse among team members. For example, once on Unix using sockets, select, and TCP/IP as the developers understood patterns like Factory Method communication mechanisms. [7] and the Reactor, they could convey and justify their After six months, however, the OS platform design and implementation decisions swiftly and clear- changed to Windows NT with WIN32 named pipes, ly to other team members. In addition, patterns NETBEUI, WaitForMultipleObjects, and helped to bridge the communication gap that existed TCP/IP as the communication mechanisms. A year between software developers, managers, and nontech- later, the scope of the project changed again to inte- nical team members in marketing and sales. grate with a much larger switch management subsys- Managers and nontechnical team members often tem. All these changes involved extensive porting and could not understand the system at the level of modification of existing communication software. detailed object models or source code. However, In such a volatile environment, reusing design pat- they frequently could understand and evaluate the terns was often the only viable means of leveraging consequences and trade-offs among software archi- previous development expertise. For example, funda- tecture concepts that were expressed as patterns. mental differences in the I/O mechanisms available Their feedback was valuable to ensure that our tech- on Windows NT and Unix precluded the direct reuse nical solutions did not drift away from the overall sys- of Reactor pattern implementations across those OS tem requirements. platforms. We were, however, able to reuse the Reac- Pattern names should be chosen carefully and used con- tor pattern itself, customizing portions of it to con- sistently. For patterns to achieve widespread use on a form with the characteristics of the OS platforms. project, developers must share an unambiguous This reduced project risk significantly and simplified vocabulary of common patterns. Selecting appropri- our redevelopment effort. ate pattern names is hard, due to the tension between Pattern descriptions should contain concrete examples. parsimony and descriptiveness. Concise names like Because patterns abstract the properties of successful Reactor or Iterator are appealing because they con- designs, they are not limited to a single implementa- vey the essence of a pattern with minimal verbal tion. As described previously, this makes it possible to effort. This brevity is conducive to rapid-fire design evolve and adapt patterns to changes in environ- brainstorming sessions. However, these verbal short-

COMMUNICATIONS OF THE ACM October 1995/Vol. 38, No. 10 69 hands can be confusing unless developers have inter- The focus should be on developing patterns that are nalized the underlying concepts and can associate strategic to the domain and reusing existing tactical pat- them immediately with the appropriate patterns. terns. Existing pattern catalogs [3, 7] do an excellent We addressed this problem by publishing more job of documenting many domain-independent, tac- descriptive aliases along with our patterns. For exam- tical patterns (such as Factory Method, Abstract Fac- ple, the Reactor pattern’s alias was “dispatch handlers tory, and Singleton). Tactical patterns have a automatically when events occur from multiple relatively localized impact on a software architecture. sources.” Ensuring names and aliases are used consis- For instance, the [7] allows elements tently throughout a project reduces the likelihood in a collection to be accessed sequentially without vio- that developers will waste time debating the conse- lating data encapsulation. Although this pattern is quences, or structure of a pattern, only to realize they widely applicable, the problem it addresses does not were actually talking about different patterns, or dif- have sweeping architectural implications. ferent variations of the same pattern. In contrast, strategic design patterns have an exten- Patterns explicitly capture knowledge that experienced sive impact on the software architecture for solutions developers already understand implicitly. Therefore, after in a particular domain. For example, the Half- being introduced to design patterns, many developers Sync/Half-Async pattern [15] decouples synchronous adopted pattern nomenclature and concepts eagerly. I/O from asynchronous I/O in a system to simplify This enthusiasm stemmed in part from the fact that concurrent programming effort without degrading pattern descriptions explicitly codified knowledge they execution efficiency. This pattern greatly simplifies understood intuitively. In this case, the use of patterns synchronization strategies in complex concurrent sys- helped experts document, discuss, and reason system- tems (such as BSD Unix). We focused most of our atically about sophisticated architectural concepts. energy on documenting patterns related to our In addition, explicitly capturing expertise through domain (communication software), and we reused patterns helps to impart this knowledge to less experi- existing tactical patterns rather than reinventing them. enced developers. For example, the Reactor pattern Focusing on strategic domain patterns also helped to reused across OS platforms in the Ericsson project rep- minimize the likelihood of pattern overload. resented knowledge gained over years of experience Rewards should be institutionalized for developing pat- with event-driven communication software on many terns. Unfamiliar design paradigms and methods may projects at different companies. By carefully docu- be perceived as threats to the traditional power struc- menting key patterns in our domain, we were able to ture and base of expertise in an organization. We preserve and share this expertise. This saved develop- observed a manifestation of this problem in which ers a great deal of time that would have otherwise been some developers were reluctant to share their spent rediscovering these patterns in new contexts. domain patterns. They viewed this knowledge as a Patterns may lead developers to think they know more competitive advantage over other developers. These about the solution to a problem than they actually do. One types of problems are indicative of deeper issues relat- downside to the intuitive nature of patterns is that ed to the reward structure in a corporate culture, developers may not fully appreciate the challenges which is often hard to change [4]. We addressed this associated with implementing a pattern. Simply problem to the extent possible by instituting incen- knowing the structure and participants in a pattern tives for developing useful pattern descriptions. (such as the Reactor pattern) is only the first step. As These descriptions were counted as “deliverables” described in [16], a significant development effort used to measure individual performance. We mea- and commitment of time and resources may be nec- sured the utility of design patterns by how widely they essary to implement a pattern correctly, efficiently, were adopted and used successfully (particularly by and portably in a particular context. We addressed developers other than the original authors). this problem by continually emphasizing to develop- Useful patterns arise from practical experience. There- ers that learning patterns complements, but does not fore, we found it was important to work closely with substitute for, solid design and implementation skills. domain experts in order to identify and document key Everything should not be recast as a pattern. Another patterns in the communication domain. One conse- downside to the intuitive nature of patterns is that it quence of the experiential basis of patterns is that they may lead to pattern overload. We noticed that the ben- are discovered “bottom up” rather than invented “top efits of patterns became diluted if too many aspects of down.” One sign that pattern overload is taking place a project were expressed as patterns. This problem is that developers start planning to “invent patterns.” arose when development practices were relabeled as Patterns help ease the transition to object-oriented patterns without significantly improving them. For technology for developers who were trained in tradi- example, some developers spent a great deal of time tional design techniques. Many patterns in our com- recasting relatively mundane concepts (such as bina- munication frameworks (such as the “pipes and ry search, building a linked list, or recursion) using filters architecture” [3]) originated in non-object-ori- pattern form. Although this was intellectually satisfy- ented contexts, such as operating systems and data- ing, pattern overload became counterproductive bases. By explicitly recognizing and rewarding the when it did not markedly improve software quality. experiential basis of useful patterns, we were able to

70 October 1995/Vol. 38, No. 10 COMMUNICATIONS OF THE ACM experiences leverage valuable developer expertise from earlier pattern descriptions thoroughly. This is another rea- design paradigms [6]. son why documenting patterns should be institutional- Patterns are validated by experience rather than by test- ized in an organization’s reward structure. ing, in the traditional sense of “unit testing” or “inte- Pattern descriptions explicitly record engineering trade- gration testing” of software. This can be problematic offs and design alternatives. Because pattern descrip- because it is hard to determine when a pattern tions explicitly enumerate consequences and description is complete and correct. The most effec- implementation trade-offs, they can be used to tive way we found to validate our patterns was record why certain design choices were selected and

through periodic pattern reviews. These reviews others rejected. For example, the description of the Object Technology helped to enrich the pattern vocabulary within and Reactor pattern in the section “Example” explains across development teams. We modeled these pat- precisely when to apply the pattern (e.g., when each tern reviews as “writer’s workshops.” At these reviews, event can be processed quickly) and when to avoid it developers from different teams presented useful pat- (e.g., when transferring large amounts of bulk data). terns they observed in their software. Group mem- If this rationale is not captured explicitly, it may be bers discussed the strengths and weaknesses of each lost over time. This loss deprives maintenance teams pattern, accentuating positive aspects of the patterns, of critical design information and makes it difficult to sharing their own experience, and suggesting motivate strategic design choices to other groups improvements in content and style. within a project or organization. Pattern authors should be directly involved with appli- The contexts where patterns apply and do not apply cation developers and domain experts. We found that iso- must be carefully documented. When developers first lating pattern authors from development teams write pattern descriptions, they tend to emphasize the resulted in overly abstract patterns that did not capture benefits of the patterns without thoroughly covering the essence of successful designs. This is similar to the the drawbacks of using the pattern in certain contexts. problem that arises in large-scale reuse initiatives that For example, as described in the previous paragraph, become disconnected from application development. the Reactor pattern can be an inefficient event demul- In both cases the resulting software artifacts can be too tiplexing mechanism on multiprocessor platforms general to solve the actual domain requirements. We because it serializes application concurrency at a addressed this problem by using the pattern review coarse-grained level [9]. If this caveat is not explicitly techniques described previously to glean system-level captured in a pattern description, developers may patterns from domain experts on the projects. These apply the pattern inappropriately. Therefore, pattern patterns were incorporated into the projects following descriptions should enumerate both the benefits and careful scrutiny in pattern reviews. the drawbacks of a pattern, as well as motivate the con- Integrating patterns into a software development process text in which the pattern does or does not apply. is a human-intensive activity. Like other software reuse Successful pattern descriptions capture both structure technologies, reuse of patterns does not come without and behavior. Expressing the behavioral aspects of a cost [6]. Identifying and documenting useful patterns pattern is hard because behaviors involve dynamic requires both concrete experience in a domain and the collaboration between participants. However, pat- ability to abstract away from concrete details to capture terns that do not clearly describe dynamic behavior the general properties of patterns. We found that rela- are difficult to understand and apply. We found tively few individuals possess both these skills with equal object interaction diagrams and object interaction proficiency. Therefore, engaging groups of developers graphs were particularly useful for depicting key col- with diverse backgrounds and skills in pattern review laborations in a design without requiring the atten- sessions was essential to leverage patterns effectively. tion to detail necessary to understand source code. However, pattern reviews required a significant Patterns facilitate training of new developers by allow- investment by organizations. The review process is fun- ing developers joining the projects to absorb the key damentally interactive and creative, rather than auto- strategies and tactics in the software design quickly. mated and rote. Organizations that do not actively We exposed developers to our pattern documenta- encourage these reviews (e.g., due to tight schedules tion before having them delve into the software. We or due to a view that software development should be found that the ability to express the intent, structure, a mechanical process) may devote inadequate time and behavior of our frameworks in terms of patterns and developer resources to this review process. While flattened the learning curve for new developers by we generally found the educational benefits of the pat- giving them a broad understanding of the architec- tern reviews justified the costs, we also recognized that ture in our communication frameworks. this style of review process does not scale up easily. For We expect that this aspect of patterns will prove example, experienced developers with deep knowl- useful for maintenance programmers. However, the edge of the communication domain were fertile projects at Kodak, Ericsson, and Motorola are all new sources of strategic and tactical patterns, as well as systems that have not yet entered the long-term main- invaluable mentors in pattern reviews. However, these tenance phase. We are collecting additional informa- experts were often very busy with other tasks, and tion on how patterns affect maintenance over the could not always spare much time to write or review software life cycle.

COMMUNICATIONS OF THE ACM October 1995/Vol. 38, No. 10 71 Implementation

he Reactor pattern can be implemented in many Synchronization—The Reactor can serve as a central event ways—Several topics related to implementing the dispatcher in multithreaded applications. In this case, critical T Reactor pattern are discussed here. sections within the Reactor must be serialized to prevent race conditions when modifying or activating shared vari- Event demultiplexing—A Reactor maintains a table of ables (such as the table holding the Event Handler sub- objects that are derived from the Event Handler base class objects). A common technique for preventing race class. Public methods in the Reactor’s interface register conditions uses mutual exclusion mechanisms like sema- and remove these objects from this table at run time. The phores or mutex variables. Reactor also provides a means to dispatch the To prevent deadlock, mutual exclusion mechanisms handle_event method on an Event Handler object in should use recursive locks. Recursive locks are an efficient response to events the application has registered to receive. means of preventing deadlock when locks are held by the The Reactor’s dispatch method blocks on an OS same thread across Event Handler method callbacks event demultiplexing system call (such as Windows NT within the Reactor. A recursive may be reacquired by WaitForMultipleObjects or Unix select) until one or the thread that owns the lock without blocking the thread. more events occur. When events occur, the Reactor This property is important because the Reactor’s dispatch returns from the event demultiplexing system call. It then method performs callbacks on application-specific Event dispatches the handle_event method on any Event Handler objects. Application callback code may subse- Handler object(s) registered to handle these events. This quently re-enter the Reactor object using its regis- callback method executes user-defined code and returns ter_handler and remove_handler methods. control to the Reactor when it completes. I/O semantics—The I/O semantics of the underlying OS sig- Registering objects vs. functions—The Reactor pattern nificantly affect the implementation of the Reactor pattern. shown in the section “Structure” registers Event Handler The standard I/O mechanisms on Unix systems provide “reac- subclass objects with a Reactor. The use of objects makes tive” semantics. For example, the Unix select system call it convenient to subclass Event Handlers in order to indicates the subset of I/O handles that may be read from or flexibly reuse and extend existing components, as well as to written to synchronously without blocking. integrate data and methods together. Another approach is Implementing the Reactor pattern using reactive I/O is to register a function rather than an object. The use of func- straightforward. In Unix, select indicates which handle(s) tions makes it convenient to register callbacks without hav- are ready to perform I/O. The Reactor object then “reacts” ing to define a new class that inherits from Event by invoking the Event Handler handle_event callback Handler. A hybrid approach can be used to support both method for each ready handle. This method performs the I/O objects and functions simultaneously. operation and the associated application-specific processing. In contrast, Windows NT provides “proactive” I/O seman- Event-handling interface—Figure 1 illustrates an imple- tics. Proactive I/O operations proceed asynchronously and mentation of the Event Handler base class interface do not cause the caller to block. An application may subse- that contains a single method (handle_event) used by quently use the WIN32 WaitForMultipleObjects sys- the Reactor to dispatch events. In this case, the type of tem call to determine when its outstanding asynchronous the event (e.g., input event, output event, signal event) is I/O operations have completed. Variations in the I/O seman- passed as a parameter to the method. This approach makes tics of different operating systems may cause the class inter- it possible to add new types of events without changing faces and class implementations of the Reactor pattern to the interface. However, this approach encourages the use vary across platforms. Schmidt and Stephenson [16] provide of switch statements in the subclass’s handle_event a detailed evaluation of how differences between proactive method, which limits extensibility. and reactive event demultiplexing affect implementations of Another way to implement the Event Handler inter- the Reactor pattern on Unix and Windows NT. C face is to define separate virtual methods for each type of event (e.g., handle_input, handle_output, han- dle_signal). This approach is easier to extend, since sub- classing does not involve switch statements. However, it requires the framework developer to anticipate the set of Event Handler methods in advance.

72 October 1995/Vol. 38, No. 10 COMMUNICATIONS OF THE ACM experiences

Implementing patterns efficiently requires careful selec- development organization’s toolkit. Patterns are no tion of language features. Existing patterns literature silver bullet that will absolve developers from having [3, 5, 7, 11] has focused primarily on software quality to wrestle with complex analysis, design, and imple- factors other than performance. This may be accept- mentation issues. In our experience, there is simply able in domains where nonfunctional requirements no substitute for creativity, experience, and diligence are more important than efficiency. For example, on the part of developers. graphical user interfaces are often judged more in Over time, the contribution of patterns will terms of their usability, extensibility, and portability become evident as software developers gain experi-

than in terms of their raw performance. ence incorporating patterns into their development Object Technology In contrast, communication software has tradi- practices. Our experience applying design patterns in tionally emphasized high performance more than large-scale distributed systems was that they con- other software quality factors. Thus, we found that tributed to developing quality software by addressing many developers were initially concerned about the fundamental challenges in large-scale system devel- performance costs of using design patterns in the opment. These challenges include communication of communication domain. To allay these concerns, architectural knowledge among developers, accom- many of our pattern implementations used C++ modating new design paradigms or architectural parameterized types extensively, rather than inheri- styles, and avoiding development traps and pitfalls tance and dynamic binding. Parameterized types do that are usually learned only by experience. not degrade the run-time efficiency of performance- critical applications because template instantiation Concluding Remarks occurs at compile time. In contrast, alternative tech- Patterns capture the static and dynamic aspects of niques for extensibility using inheritance and successful solutions to problems that commonly arise dynamic binding incur a run-time performance when building software systems. If software is to penalty in C++, due to virtual function table dis- become an engineering discipline, these successful patching overhead. practices and design expertise must be documented Patterns help to transcend “programming language- systematically and disseminated widely. Patterns are centric’’ viewpoints. Focusing on design patterns important tools for documenting these practices and helped us to move away from “programming lan- expertise, which traditionally existed primarily in the guage-centric” views of the object paradigm. This was minds of expert software architects. beneficial because it enabled experienced developers from different language communities (such as Lisp, ver the next few years a wealth Smalltalk, Ada, Eiffel, C++, C, and Erlang) to share of software design knowledge design insights of mutual interest without being dis- will be captured in the form of tracted by “language wars.” Once we moved beyond strategic and tactical patterns language syntax and semantic differences, it was that span disciplines such as remarkable how much commonality was shared by client/server programming, successful software solutions for a given design prob- distributed processing, organi- lem. However, we also found that many developers zational design, software reuse, wanted to see pattern examples illustrated with the real-time systems, business and financial systems, and programming language they were most familiar with Ohuman interface design. In addition, the following (C++ in our projects). aspects of patterns will receive increased attention in Managing expectations is crucial to using patterns effec- the next few years: tively. One recurring problem we encountered using Integration of design patterns together with frame- patterns centered on managing the expectations of works—Patterns can be viewed as abstract descrip- development team members. Some team members tions of frameworks that facilitate widespread reuse had misconceptions about precisely how and what of software architecture. Frameworks can be viewed design patterns contributed to project success. For as concrete realizations of patterns that facilitate example, the use of patterns does not guarantee flex- direct reuse of design and code. One difference ible and efficient software. Moreover, in their abstract between patterns and frameworks is that patterns are form, patterns cannot be used directly by program- described in a language-independent manner, mers in their implementations. In addition, tools do whereas frameworks are generally implemented in a not yet exist that transform design patterns into code particular language. However, patterns and frame- automatically. Custom implementation is often works are highly synergistic concepts, with neither required, unless the patterns have been integrated subordinate to the other. into a reusable framework or library. The next generation of object-oriented frame- We worked hard at Ericsson, Motorola, and Kodak works will explicitly embody dozens or hundreds of to prevent design patterns from becoming yet anoth- patterns—and patterns will be widely used to docu- er buzzword. We did this by candidly reporting the ment the form and contents of frameworks [8]. Ide- benefits and limitations of patterns and stressing that ally, systems of patterns and frameworks will be patterns are just one of many important tools in a integrated with tools like online pattern browsers that

COMMUNICATIONS OF THE ACM October 1995/Vol. 38, No. 10 73 contain hypertext links to navigate quickly through References multiple levels of abstraction. 1. Blaine, G., Boyd, M., and Crider, S. Project Spectrum: Scalable Integration of design patterns to form systems of pat- bandwidth for the BJC health system. HIMSS, Health Care Com- munications, 1994, pp. 71–81. terns—Most literature on patterns is currently 2. Booch, G. Object Oriented Analysis and Design with Applications 2d organized as design pattern catalogs [3, 5, 7]. ed. Benjamin/Cummings, Redwood City, Ca., 1993. These catalogs present a collection of individual 3. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and solutions to common design problems. As more Stal, M. Pattern-Oriented Software Architecture—A System of Patterns. Wiley, NY, 1996. experience is gained using these patterns, devel- 4. Coplien, J.O. A development process generative pattern lan- opers will integrate groups of related patterns to guage. In J. O. Coplien and D. C. Schmidt, Eds., Pattern Lan- form pattern systems (also called pattern languages). guages of Programs. Addison-Wesley, Reading, Mass., 1995. These pattern systems will encompass a family of 5. Coplien, J.O. and Schmidt, D.C., Eds. Pattern Languages of Pro- related patterns that cover a particular domain gram Design. Addison-Wesley, Reading, Mass., 1995. 6. Fayad, M., Tsai, W., and Fulghum, M. Transition to object-ori- (such as communication software). In the same ented software development. Commun. ACM. To appear. sense that comprehensive application frameworks 7. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Pat- support larger-scale reuse of design and code than terns: Elements of Reusable Object-Oriented Software. Addison-Wes- do class libraries, pattern systems will support larg- ley, Reading, Mass., 1994. 8. Johnson, R. Documenting frameworks using patterns. In Pro- er-scale reuse of software architecture than will ceedings of OOPLSA ‘92, (Vancouver, BC. Oct. 1992), pp. 63–76. individual patterns. Developing comprehensive 9. Lavender, R.G. and Schmidt, D.C. Active Object: An object systems of patterns is challenging and time con- for concurrent programming. In Proceedings suming, but will likely provide the greatest payoff of the Second Annual Conference on the Pattern Languages of Pro- for pattern-based software development during grams, (Monticello, Illinois, Sept. 1995.), pp. 1–7. 10. Linton, M.A. and Calder, P.R. The design and implementation the next few years. of InterViews. In Proceedings of the USENIX C++ Workshop, Integration with popular object-oriented methods November 1987. and software process models—Patterns help to allevi- 11. Pree, W. Design Patterns for Object-Oriented Software Development. ate software complexity at several phases in the Addison-Wesley, Reading, Mass., 1994. 12. Schmidt, D.C. Acceptor and connector: Design patterns for software life cycle. Although patterns are not a soft- active and passive establishment of network connections. In ware development method or process, they com- Proceedings of the Workshop on Pattern Languages of Object-Oriented plement existing methods and processes. For Programs at ECOOP ‘95, (Aarhus, Denmark), August 1995. instance, patterns help to bridge the abstractions 13. Schmidt, D.C. A system of reusable design patterns for com- in the analysis and architectural design phases with munication software. In The Theory and Practice of Object Systems (Special Issue on Patterns and Pattern Languages, S.P. the concrete realizations of these abstractions in Berczuk, Ed.), Wiley, New York, 1995. the implementation and maintenance phases. In 14. Schmidt, D.C. Reactor: An object behavioral pattern for con- the analysis and design phases, patterns help to current event demultiplexing and event handler dispatching. guide developers in selecting from software archi- In J.O. Coplien and D.C. Schmidt, Eds., Pattern Languages of Program Design. Addison-Wesley, Reading, Mass., 1995. tectures that have proven to be successful. In the 15. Schmidt, D.C. and Cranor, C.D. Half-Sync/Half-Async: An implementation and maintenance phases, they for efficient and well-structured concur- help document the strategic properties of software rent I/O. In Proceedings of the Second Annual Conference on the Pat- systems at a level higher than source code and indi- tern Languages of Programs, (Monticello, Illinois, Sept. 1995 ), vidual object models. pp. 1–10 16. Schmidt D.C., and Stephenson, P. Experiences using design This article just scratches the surface of activities patterns to evolve system software across diverse OS platforms. the patterns community is currently engaged in. A In Proceedings of the Ninth European Conference on Object-Oriented number of books [3, 5, 7, 11] have been published Programming, (Aarhus, Denmark), August 1995. (or will soon be published) on these topics. The Pat- About the Author: tern Languages of Programming conference [5] is an DOUGLAS C. SCHMIDT is an assistant professor of Computer Sci- annual forum dedicated to improving the expression ence at Washington University in St. Louis. Current research inter- of patterns. There are also pattern workshops at ests include parallel and distributed systems, distributed object object-oriented conferences (such as OOPSLA, computing, object-oriented design patterns, and high-perfor- ECOOP, and USENIX COOTS). The World Wide mance communication subsystems and protocols. Author’s Present Address: Department of Computer Science, Box 1045, Washington Web URL http://st-www.cs.uiuc.edu/users/patterns University, St. Louis, MO 63130. email: [email protected]; contains a comprehensive online reference to pat- http://www.cs.wustl.edu/~schmidt/ tern-related material.

Acknowledgments Permission to make digital/hard copy of part or all of this work for person- I would like to thank Mohamed Fayad, , al or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, the copyright Adam Porter, Tim Harrison, and Ehab Al-Shaer for notice, the title of the publication and its date appear, and notice is given improving the quality of this article. I would also like that copying is by permission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permis- to thank Paul Stephenson of Ericsson for many hours sion and/or a fee. of discussion on design patterns and techniques for developing object-oriented communication software frameworks. C © ACM 0002-0782/95/1000 $3.50

74 October 1995/Vol. 38, No. 10 COMMUNICATIONS OF THE ACM