One claimed benefit of deploying design patterns is facilitating maintainers to perform anticipated changes. However, it is not at all obvious that the relevant design patterns deployed in software will invariably be utilized for the changes. Moreover, we observe that many well-known design patterns consist of three types of programming elements (called participants), and that performing an anticipated change typically entails multiple tasks related to different types of participants. This paper studies empirically whether maintainers utilize deployed design patterns, and when they do, which tasks they more commonly perform. Our experiments show that almost all subjects perform the task of adding new concrete participants, fewer perform the tasks involving clients, whereas even fewer perform the tasks involving abstract participants. Furthermore, utilizing deployed design patterns (by performing whichever of the corresponding tasks) is found to be statistically associated with the delivery of less faulty codes.

Program refactoring using design patterns is an attractive approach for facilitating anticipated changes. Its benefit depends on at least two factors, namely the effort involved in the refactoring and how effective it is. For example, the benefit would be small if too much effort is required to translate a program correctly into a refactorized form, and whether such a form could effectively guide maintainers to complete anticipated changes is unknown. A metric of effectiveness is the maintainers' performance, which can be affected by their work experience, in realizing the changes. Hence, an interesting question arises. Is program refactoring to introduce additional patterns beneficial regardless of the work experience of the maintainers? In this paper, we report a controlled experiment on maintaining JHotDraw, an open source system deployed with multiple patterns. We compared maintainers with and without work experience. Our empirical results show that, to complete a maintenance task of perfective nature, the time spent even by the inexperienced maintainers on a refactorized version is much shorter than that of the experienced subjects on the original version. Moreover, the quality of their delivered programs, in terms of correctness, is found to be comparable.

A design pattern provides a structure to manage a design aspect by allowing the aspect to be changed without software redesign. For example, the command pattern allows a software design to be easily reconfigured to replace a receiver of a command request or issue a new command request. To prepare for everlasting demands in diverse requirement changes, multiple design patterns are typically deployed to manage various design aspects of a software program. However, this can complicate the underlying program structure, resulting in difficulties of succeeding program revisions to preserve effective management of aspects. In particular, when design aspects cut across each other, realizing changes in one aspect likely revokes the management of other aspects. To address this problem, we propose a documentation approach to govern program revisions. In the approach, a design aspect is associated with a set of proactive views. Each view specifies how an implementation of the aspect is organized so that other aspects can be managed at the same time. The views capture the class relationships that must be kept to preserve effective management of aspects. The approach is illustrated using a pattern-based hotel management system.