Traditional Design Patterns
Q1: Would having multiple patterns for the same problem be possible?
Q2: if it is true, what are the adverse complications?
[2] Same Problem, but Multiple Patterns!: The Common Problem of Duplication [1, 2]
[2] Same Problem, but Multiple Patterns!: The Common Problem of Duplication —
Professor Dr. M.E. Fayad, SJSU, AITG, AEEH PRESS, i-SOLE, INCs
In trying to make something new, half the undertaking lies in discovering whether it can be done.
Once it has been established that it can be done, duplication is inevitable. Helen Gahagan [3]
With the tremendous growth of the patterns community, it becomes fairly natural to find similar patterns that attempt to address almost the same problem. The nature and format of the design, as the solution space, makes it perfectly acceptable for developers to find different patterns, which provide dissimilar approaches to solve the same problem. However, it is not quite normal in analysis, as the problem space, to find multiple analysis models, which analyze the similar problem, which result in patterns that are remarkably different in their structure and architecture.
For instance, now consider the Account pattern. There is more than one pattern that models this Account problem; yet they are all, quite different (see Figures 1 and 2). This suggests that something is wrong with these models, as patterns. Perhaps, they have many redundant objects that have nothing to do with the underlying problem; therefore, the absence of these objects from other models, still allow them to work properly.
If all of these different models have worked properly in real-life projects, the use of analysis patterns becomes much more complex. Unlike designs, there is no basis for which these models are validated or endorsed. The only way that a developer can choose the right analysis pattern is to critically analyze the problem, and check which pattern makes the most sense for the given application. Consequently, the advantage of reusing analysis patterns simply vanishes.
