If a developer wishes to develop meaningful patterns, he or she will need to identify the perimeter of the problems that these patterns model or solve. In many cases, it is quite difficult and cumbersome to identify the boundary of the problems. In absence of any clear and well-set boundaries for a particular pattern, it will ultimately embody and induce a host of other problems that will be simply out of the scope of the main problem. Consequently, developers end up building large patterns that model or solve a collection of different problems instead of developing patterns for specific problems. It is important to note that this problem dominates almost all existing analysis patterns, but rarely exists in current design patterns.

For instance, consider the Account analysis pattern shown, previously in Figure 2 (See Pitfall #2). This particular pattern presents a unique situation of modeling a problem related to accounting. Unfortunately, this pattern also includes different types of patterns that lie outside the domain of the problem, such as “Institution and Institution branch”. On the first glance, it looks as if they are valid classes, but they appear irreverent, when focused solely on the essential idea of an account. In general, more the problems a pattern considers, the less general will be the nature of the problem. Consequently, the issue of reusability will become limited and seriously undermined.

On the other hand, so many design patterns possess very well defined boundaries, such as GoF patterns [1], where each pattern solves a specific and pre-defined problem, without considering the surrounding environment.

References:

1. Gamma, E. et al., “Design Patterns: Elements of Reusable Object-Oriented Software” Addison-Wesley Professional Computing Series. Addison-Wesley Publishing Company, New York, 1995.