ACM Computing Surveys 28A(4), December 1996, Copyright © 1996 by the Association for Computing Machinery, Inc. See the permissions statement below.

Using Design Patterns to Develop Reuseable Object-Oriented Software

Douglas C. Schmidt
Department of Computer Science
Washington University, St. Louis
St Louis, MO 63130,

Abstract: Despite decades of research on OO programming languages and methods, widespread reuse of design and components has not yet materialized. The main thesis of this position paper is that without a concentrated focus on fundamental design patterns underlying software systems, widespread reuse based on OO techniques will remain elusive. This is a serious problem for mission/life critical domains (such as telecommunications, distributed medical imaging, and electronic commerce systems), where developing complex software systems from scratch is prohibitively expensive and error-prone.

Categories and Subject Descriptors: D.2.10 [Software Engineering] Design; D.2.6 [Software Engineering] Programming Environments; D.3.2 [Programming Languages] Object-Oriented Languages

General Terms: Object-Oriented Programming

Additional Key Words and Phrases: frameworks, design patterns, distributed objects, programming languages

The Problem

Object-oriented (OO) techniques are a promising means to achieve widespread reuse of software designs and components. Like so many other promising techniques in the history of software, however, OO has yet to deliver widespread improvements in the quality and quantity of reuse. There have certainly been successes -- sophisticated frameworks of reusable components are now available in many OO languages running on many OS platforms. In general, however, these frameworks have been limited to certain well traveled domains, such as graphical user-interfaces. Moreover, component reuse is often limited to third-party libraries and tools, rather than being an integral part of the software development processes in most organizations.

A number of factors are responsible for the lack of widespread software reuse. Commonly cited impediments to success include:

These factors are often tied to deeply rooted problems in corporate culture, which is hard to change. In a very real sense, these problems transcend the scope of OO and any other methodology.

Fortunately, there are ways that OO design and programming techniques can, and have, had a powerful impact on improving software reuse. In general, OO techniques facilitate reuse by enabling larger-grained abstractions and encapsulation mechanisms than preceding paradigms (such as procedural design and structured programming). OO practitioners have traditionally focused on the design and implementation of reusable components in terms of artifacts such as classes, class categories, objects, modules, and subsystems.

Unfortunately, many OO reuse efforts have focused on language features (such as inheritance, polymorphism, generics, and exception handling) or design methods and notations (such as Booch vs. OMT vs. Shlaer/Mellor). I believe the quest for solutions in languages and methods is alluring because it appears to absolve us from having to address the tough issues. Chief among these is capturing and articulating the abstractions and components required to build widely reusable software in complex domains (such as real-time avionics, business data processing, telecommunications, on-line transaction processing, and distributed communication systems).

Another vexing challenge for developers and analysts is translating their domain expertise into reusable software components. A number of approaches (such as transformational systems, expert systems, and domain-specific software architectures) have been advocated over the past decade in both in academia and industry. Few, if any, of these approaches have achieved widespread success. A major impediment is that many of these approaches don't integrate well into the development processes (or lack thereof) found in contemporary software organizations. For instance, developers in most organizations aren't fluent in formal methods.

In addition, traditional approaches to reuse based on automated domain analysis have often ignored fundamental challenges in large-scale software system development. These challenges include communication of architectural knowledge among developers; accommodating new design paradigms or architectural styles; resolving non-functional forces such as reusability, portability, and extensibility; and avoiding development traps and pitfalls that are usually learned only by experience.

A Solution

Achieving widespread reuse of complex software components requires a concerted focus on the fundamental design patterns that underly software systems. A design pattern is a successful solution to a set of forces and problems that arise when building software. Patterns aid the development of reusable software by expressing the structure and collaboration of components to developers at a level higher than (1) source code or (2) object-oriented design models that focus on individual objects and classes. Therefore, patterns facilitate reuse of software architecture, even when other forms of reuse are infeasible (e.g., due to fundamental differences in operating system mechanisms or programming language features).

If OO software is to become an engineering discipline, the successful practices and design expertise must be documented systematically and disseminated widely. Patterns are important tools for documenting these practices and expertise, which traditionally existed in the minds of expert software architects or buried deep within the source code of complex systems. Without a thorough understanding of the patterns underlying domain-specific architectures, design, and implementations, OO software reuse will remain a largely unfulfilled promise.

Current Progress and Future Directions

Over the past decade, extensible frameworks (such as MacApp, ET++, Interviews, Choices, MFC, implementations of OMG CORBA and Microsoft DCOM, and Java's AWT) have played a large role in shaping contemporary software architectures. More recently, a body of literature on design patterns [1,2,3,4] has emerged. These patterns identify, document, and catalog successful solutions to common software problems. The patterns captured by this literature have already had a significant impact the construction of commercial software [6,7]. In these systems, patterns have been used to enable widespread reuse of communication software architectures, developer expertise, and object-oriented framework components.

Over the next few years, we anticipate a wealth of software design knowledge will be captured in the form of patterns and frameworks. These patterns and frameworks will span domains and disciplines such as concurrency, distribution, organizational design, software reuse, real-time systems, business and electronic commerce, and human interface design. We expect the following aspects of patterns and frameworks will receive particular attention [6]:

1. Integration of design patterns with frameworks and other design paradigms.

Framework developers are confronted with many challenging design tradeoffs. One of the most crucial is determining which components in a framework should be variable and which should be stable. Insufficient variation makes it hard for users to customize framework components. This results in a framework that cannot accommodate the requirements of diverse applications. Conversely, insufficient stability makes it hard for users to comprehend and reply on the framework. Inflexibility and instability can create a framework that is awkward to use and unable to satisfy other requirements (such as run-time performance).

Many design patterns are intended to decouple the stable portions of software from the variable portions. Therefore, it is not surprising that some of the most useful patterns [1] describe frameworks. Such patterns can be viewed as abstract descriptions of frameworks that facilitate widespread reuse of software architecture. Similarly, frameworks can be viewed as concrete realizations of patterns that facilitate direct reuse of design and code.

One difference between patterns and frameworks is that patterns are described in a language-independent manner, whereas frameworks are generally implemented in a particular language. However, patterns and frameworks are highly synergistic concepts, with neither subordinate to the other. We expect that the next generation of object-oriented frameworks will explicitly embody many patterns and that patterns will be widely used to document the form and contents of frameworks.

2. Integration of design patterns to form pattern languages.

Much of the existing literature on patterns is organized as catalogs of design patterns [1,4]. These catalogs present a collection of relatively independent solutions to common design problems. As more experience is gained using these patterns, developers and authors will increasingly integrate groups of related patterns to form pattern languages. Pattern languages define architectural styles that guide designers as they weave patterns to build entire systems. A pattern language may generate a software system (according to architectural styles such as real-time, business, or electronic commerce), or it may guide any system endeavor, including organization and process, human interface design, and teaching.

Just like application frameworks support larger-scale reuse of design and code than do stand-alone functions and class libraries, so to will pattern languages support larger-scale reuse of software architecture and design than do individual patterns. Developing pattern languages is challenging and time consuming, but we believe they will ultimately provide the greatest payoff for developing high quality software.

3. Integration with current software development methods and software process models.

Patterns help to alleviate software complexity at several phases in the software lifecycle. For instance, patterns can help developers navigate through alternative choices within a particular development phase. In the analysis and design phases, for example, patterns can help guide developers in selecting from software architectures that have proven to be successful. Likewise, in the implementation and maintenance phases, patterns help document the strategic properties of software systems at a level higher than source code and models of individual software modules.

In addition, patterns can help developers navigate abstraction boundaries across software development phases. For instance, patterns help to bridge the abstractions in the upstream phases (such as domain analysis and architectural design) with the concrete realizations of these abstractions in downstream phasese (such as implementation and maintenance).

The patterns and pattern languages that exist today do not yet form a comprehensive software development method or complete process guide. However, they do complement existing approaches by focusing on non-functional forces (such as backwards compatibility or architectural extensibility) that are often not addressed by conventional development methods and processes.

Concluding Remarks

This position statement just scratches the surface of activities the patterns community is currently engaged in. The Pattern Languages of Programming conference [2,3] is an annual forum dedicated to improving the expression of patterns. There are also pattern workshops at on object-oriented conferences (such as OOPSLA, ECOOP, and USENIX COOTS). To find out about books, online papers, electronic mailing lists, and conferences on patterns and frameworks, see the Patterns Home Page.


[1] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Reading, MA: Addison-Wesley, 1995.

[2] J. O. Coplien and D. C. Schmidt, eds., Pattern Languages of Program Design, Vol 1. Reading, MA: Addison-Wesley, 1995.

[3] J. O. Coplien, J. Vlissides, and N. Kerth, eds., Pattern Languages of Program Design, Vol 2. Reading, MA: Addison-Wesley, 1996.

[4] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern-Oriented Software Architecture - A System of Patterns. Wiley and Sons, 1996.

[5] D. C. Schmidt, R. Johnson, M. Fayad., Communications of the ACM, Special Issue on Design Patterns, Vol. 39, No. 10, October, 1996.

[6] D. C. Schmidt, Experience Using Design Patterns to Develop Reuseable Object-Oriented Communication Software, Communications of the ACM, Special Issue on Design Patterns, Vol. 38, No. 10, October, 1995.

[7] Kent Beck, Ron Crocker, James O. Coplien, Lutz Dominick, Gerard Meszaros, Frances Paulisch, and John Vlissides. ``Industrial Experience with Design Patterns.'' in Proceedings of ICSE '96, March, 1996

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation of the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or

Back to Douglas C. Schmidt's home page.

Last modified 11:34:23 CDT 28 September 2006