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:

• Organizational factors -- such as the effort required to catalog, archive, and retrieve reusable components;

• Economic factors -- such as the lack of adequate chargeback schemes and monetary incentives in many development organizations;

• Political factors -- such as not wanting to share components with rival groups;

• Psychological factors -- such as perceived threat to job security and the ubiquitous ``not invented here'' syndrome.

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.

As I've mentioned many times before, I believe one of the most promising techniques for achieving widespread reuse of software is by capturing and documenting key design patterns that arise when solving common software problems. Patterns facilitate reuse of software architecture and expertise, both of which are crucial to developing high quality frameworks and components.

My experience applying design pattern-based reuse strategies in production communication systems has been very positive. For instance, on the ACE project at Washington University we've significantly reduced the software development, maintenance, and training effort for our commercial collaborators by documenting the intent, structure, and behavior of ACE's reusable network programming components in terms of the patterns they reify. In addition, focusing on patterns has enabled us to reuse communication software architectures even when reuse of algorithms, implementations, interfaces, or detailed designs was not feasible due to differences in OS platforms. Incidentally, some of the communication software patterns implemented in ACE are available online at www.dre.vanderbilt.edu/~schmidt/patterns-ace.html.

If 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 primarily in the minds of expert software architects. Without a thorough understanding of the patterns underlying domain-specific architectures, design, and implementations, OO software reuse will remain an unfulfilled promise.

Back to C++ Report Editorials home page.

Last modified 18:06:19 CST 25 January 2019