Article Preview
Top1. Introduction
One of the challenging tasks in software industry is to produce high quality products that are maintainable and reusable. To achieve this goal, software engineering principles are proposed, best practices are summarized, software development tools are built, formal methods are utilized, and so on and so forth. Among these efforts to achieving high quality standard and reducing development cost is the adoption of design patterns (McNatt & Bieman, 2001; Shalloway & Trott, 2005). Design patterns are generalized solutions for common design problems in object-oriented systems (Mor et al., 2014). The idea that supports design patterns is that although the problems of different programs we are dealing with could belong to different domains, the internal data relations or functional procedures of these applications could be similar. Therefore, similar solutions could be reused to tackle these similar problems.
The use of design patterns can provide several advantages, such as increasing reusability, modularity, and product quality of a program. Design patterns can also improve the consistency between program design and program implementation and help achieve better coordination between the design and the implementation teams (Hasheminejad & Jalili, 2012; Hussain et al., 2017). Since the introduction of design patterns (Gamma et al., 1995), software developers and researchers have identified over 20 patterns, many of which have been widely used in object-oriented programs. Recent studies found that design patterns have also been widely used in open-source programs (Ampatzoglou et al., 2011a; Sfetsos et al., 2014), which greatly facilitated the rapid growth and distribution of open-source projects.
Although design patterns can provide tested, proven solutions to representative and often-occurring software design problems, they are not necessarily the best design solutions with respect to software quality. First, while design patterns could be used to solve certain design problems, they might introduce new problems and reduce the system quality (Ampatzoglou et al., 2011a). Second, the use of design patterns should be context-based; an inappropriate use of design patterns could increase the system complexity and accordingly reduce software quality (Ampatzoglou et al., 2011b). To address this issue, extensive research has been performed in this area to study how design patterns can affect software quality, including reusability and maintainability (Ampatzoglou et al., 2011a; Ampatzoglou et al., 2011b). For example, theoretical analysis has been performed on several design patterns to see how they might affect complexity measurements (Huston, 2001). However, little work has been reported to investigate the relationship between design patterns and software design quality both theoretically and empirically.
This paper presents a comprehensive study to investigate the relationship between design patterns and design quality. The study is carried out in three stages. In Stage 1, we theoretically analyze the complexity and design quality of some representative design patterns; In Stage 2, we empirically study the correlation between software complexity and the usage of design patterns in real world projects; In Stage 3, we collect and analyze user evaluations of design patterns.
The remainder of the paper is organized as follows. Section 2 reviews related work in the quality analysis of design patterns. Section 3 presents the background knowledge of this study. Section 4 describes the theoretical analysis of the complexity of design patterns. Section 5 presents the empirical study of the relationship between design patterns and software structural complexity. Section 6 presents user evaluations of design patterns. Section 7 compares the results of theoretical analysis, empirical evaluation, and user experience about design pattern quality. Threats to validity are discussed in Section 8. Conclusions appear in Section 9.
This paper extends our earlier book chapter on the same topic (Yu & Ramaswamy, 2014). Below listed the major differences between our original book chapter and this paper.