Outdated and Jaded Patterns or Fresh and Everlasting Patterns: Choose your Pick!

M.E. Fayad, Ph.D

As these reasons might provide a useful insight into why patterns die or become outdated, they also provide many ideas and clues about the critical question: why have not patterns fulfilled the expectation of playing a crucial role in software development?

Even though many of us think of a pattern as a “possible” solution to a problem, it may or may not really work for every problem, and hence, it is up to the discretion of the developer to either use it or just develop a customized solution. If patterns can die, then is there a risk in heavily utilizing them during development? One obvious and short answer is yes, the patterns may become a legacy system, and developer must deal with upgrading, modifying, or enhancing that system, given that the replacement of the entire system is both costly and time consuming.

Returning to the three reasons cited above, that might cause a pattern to die or become outdated, they can be rephrased to answer the question of, why patterns are not as effective as developers may have envisioned during the earlier phases of development.

We can rewrite these reasons as follows: patterns are not as effective as they should be, because they do not present the best possible solution to the problem at hand and there is always a better solution than what the pattern proposes in real. So, what causes a solution to a specific problem be classified as a “bad” solution, or why can a better solution to the same problem evolve?

If patterns are technology inter-dependent, then the frequency of changes in the technology will drive the frequency of changes in the patterns usage as well. Consequently, rapid changes in technology will render these solutions obsolete and outdated, even before they get the chance to become accepted. This obviously contradicts the original goal of patterns as reusable artifacts.

It does not make any sense to use those patterns that are already obsolete and outdated!

References:

[1] Buschmann, F. et al., “Pattern-Oriented Software Architecture, A System of Patterns”, John Wiley & Sons Ltd, Chichester, 1996

[2] Alexander, Christopher. 1979. Timeless Way of Building. New York, NY: Oxford University Press.

[3] Christopher Alexander; Sara Ishikawa; Murray Silverstein 1977 A Pattern Language:
Towns • Buildings • Construction. Oxford University Press.

Leave a Comment

Name: (Required)

E-mail: (Required)

Website:

Comment:

Spam Protection by WP-SpamFree