Another major challenge that confronts pattern designers while designing today’s patterns is the absence of a clear guidance or methodology for already extracting patterns. GOF [1] has stated explicitly in their book on page 355:”…that finding patterns is much easier than describing them.” Creating and documenting patterns that everyone can read, understand and reuse them in no easy task!

Theoretically, patterns seem to be obvious and easily located in a given developed system. The GOF recipe for extracting patterns is quite simple: by observing “enough” systems, one can easily identify many patterns. Nevertheless, how much does “enough” mean in the real sense? Is it two times or a hundred times? On the other hand, is it possible to quantify it?

The idea is not to merely identify or pinpoint a few classes that do a specific task and later consider them a pattern. Without some clear guidance, such extractions might result in incomplete patterns, which obviously miss some of the classes that make the pattern perform the required function. Alternatively, the system’s model can end up extracted itself, instead of the pattern “by including too many classes that are outside the boundary or domain of the problem”. It also requires dedicated work to know what really constitutes a pattern that lies within a system. The confusion arises, when some of the functional relationships are scattered all over the system model. In this case, extracting a set of classes that form the pattern is very complex and tedious.

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.