Traditional Design Patterns

Q1: Why is selecting the right pattern a real challenge?

Q2: What do the developers need to choose the correct pattern?

[3] Choosing the Right Pattern- Real Challenges [1, 2]

[3] Choosing the Right Pattern- Real Challenges

Professor Dr. M.E. Fayad, SJSU, AITG, AEEH PRESS, i-SOLE, INCs

A key ingredient in innovation is the ability to challenge authority and break rules. Vivek Wadhwa [3]

 

The existence of a many number of patterns that address the same problem will naturally raise the perplexing and mysterious question: Which pattern shall we choose? Today, the decision to choose a particular pattern has become a crucial issue, while applying patterns.

The problem of pattern selection falls in two main categories. The first is the selection among different patterns that sound more relevant to the problem existing in existence. (For instance, separating the models of the system from their views is possible through several different patterns. One might use the Model-View-Control pattern, while others may choose to utilize the Pipe and Filter design pattern. Each pattern has its own philosophy and idea, and using each of them will require different considerations in the design of the system, although both are still valid solutions for the problem.) The second is selecting among the same patterns, which claim to address the problem at hand. (For example, choosing between the account problem in Figure 1(refer to Figure-1 of pitfall 2) and the one in Figure 2 (refer to Figure-2 in pitfall 2); they both have the same name, but are very different in structure.)

The pattern community is aware of the first type of the selection problem (selection among different patterns), and thus have proposed some advanced techniques that can facilitate the selection process. For example, Gamma, et al (the authors popularly known as the Gang of Four (GOF) proposed six different approaches to choose a design pattern [4]. Another example is the selection procedure, as proposed by Buschmann in [5]. However, these approaches have many and severe limitations. The main limitation with these approaches is that designers developed them for local use, for selection of only the patterns presented, within the book and not for any group of patterns. In fact, these designers tied these approaches with patterns classifications and documentation style. Thus, these approaches are not applicable in a general way, to select among different patterns. Another sever limitation is their dependence on searching mechanisms, where the developer needs to scan and probe different parts of the template, before making the final choice. With the tremendous growth of number of patterns today, this type of searching will impose and force a great burden on developers and complicates the use of patterns in development. Apart from time consuming, searching patterns could be very difficult, since the pattern, templates are not standard, and some of them have additional fields that are not present in others. In addition, pattern descriptions depend heavily on the pattern writer’s style. Therefore, the problem description might be too vague for the pattern reader and force him to skip the pattern as an option, simply because the reader did not understand the nature of problem the pattern was addressing.

On the other hand, designers have not attempted to address the second type of selection problem. That is, the problem of selecting among the same pattern that addresses the problem at hand, as shown in the Accounts example above. In design patterns, several factors can assist in choosing the appropriate pattern for such situations. One of these factors relates to the implementation issues. The implementation language used in the development of a project could make the implementation of one pattern look less complex, compared to the other. Thus, a decision on which pattern to choose becomes more obvious and apparent.

Another aspect that might help in choosing the appropriate design pattern relates to the solution that it proposes, and how it resolves the forces of the problem it solves. It is very hard for one solution to resolve all the forces of the problem it solves. Therefore, different designs may weigh the forces of the problem in a different manner, which is the normal expectation. The developer can then decide on which pattern to choose, depending on which forces are more critical to the system.

However, choosing the suitable design pattern is not that straightforward nor is it very easy, even with the guidelines described above. There are still many problematic issues, which are associated with making the right decision. For instance, we should remember that patterns aim at helping novice developers, as well as seasoned and skilled professionals. Therefore, with the assumption that the design patterns described only for the novice and average OO developers, it is still difficult to distinguish between different design solutions. Most of the decision-aiding factors require some level of previous experience. It might not be too obvious for a novice developer, how different forces conflict with each other, and which are the most critical forces for the system.

With analysis patterns, the situation is far more complex. Unlike design patterns, where decisions directed at choosing the appropriate design, the choice between different analysis patterns is a matter of finding the right analysis, instead of the appropriate analysis. Consequently, designers make decisions based on validating the different patterns, and examining how accurate they are in modeling the corresponding problem. Without considering time as a critical factor in analysis, validating analysis patterns is not a defined or systematic process to apply. Thus, it is very difficult to guarantee the right type of decision. Therefore, patterns will lose their main advantage of being an easier way to develop systems. Moreover, novice developers will most likely not have the adequate experience for examining different analysis models and choosing the right one.

In conclusion, there should be processes that are more effective or relevant tools that help developers to select the right patterns for the given job. These processes and techniques should not be restricted to specific kinds or groups of patterns, as is the case today.

References

[1] M.E. Fayad. Stable Design Patterns (SDPs) (BASE)” Aeeh Press, Inc, San Jose, CA. December 2024

[2] M. E. Fayad. “Stable Design Patterns for Software and Systems” Boca Raton, FL: Auerbach Publications, Taylor & Francis Catalog #: K24656, September 2017. ISBN-13: 978-1-4987-0330-7

[3] Vivek Wadhwa is an Indian-American technology entrepreneur and academic, Wiki

[4] Gamma, E. et al., Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley Professional Computing Series. Addison-Wesley Publishing Company, New York, 1995.
[5] Buschmann, F. et al., Pattern-Oriented Software Architecture, A System of Patterns, John Wiley & Sons Ltd, Chichester, 1996.