Experience Using Design Patterns to Develop Reusable Object-Oriented Communications Software.

Author(s): Douglas C. Schmidt
Venue: Communications of the ACM, Vol. 38, No. 10
Date: October 1995

Type of Experiement: Other
Sample Size: 2
Class/Experience Level: Professional

Quality
3

Language: C++
Size of Projects: large

Threats to validity
Internal: quality of pattern reviews
External: patterns mostly applied in one domain

Software Domain: telecommunication software

Summary:
In this paper authors describe personal experience and lessons learned when creating and applying design patterns in the domain of telecommunications software. First the paper gives an overview of one of the patterns that was developed at Motorola while working on event-driven software. Then it talks about the benefits and the burdens encountered while applying and creating new patterns, and gives some advice for effective use of patterns.

The new patter that was developed is called Reactor. Its purpose is to dispatch event handlers when receiving events from multiple even sources such as a network interface or OS GUI events. Its an alternative to processing events from each source in a separate thread. Thus it avoids complexities of concurrent programming, and unnecessary resource utilization.

The major benefits of patterns that were stated include: easier portability, better communication between developers and between managers, faster integration of new developers, abstraction of languages. There are a few disadvantages the authors discovered from their experience. First developers might become reliant on design patterns without using proper design and implementation. Also developers may have the urge to implement even trivial tasks as design patterns, thus adding unnecessary complexity. Creating, validating and integrating new patterns may also take significant human resources. I thought the most important advice offered was to provide concrete examples with new design patterns, give rewards for developing new patterns, and describe trade-offs of each design pattern so that they are not applied in incorrect contexts.

0