Traditional Design Patterns
Do you know you cannot trace the design patterns within Any Systems?
[9] Untraceable Patterns-The Pitfall of the Pattern Systems [1, 2]
[9] Untraceable Patterns-The Pitfall of the Pattern Systems
Professor Dr. M.E. Fayad, SJSU, AITG, AEEH PRESS, i-SOLE, INCs
There are some problems on this planet that seem to be intractable. Richard Gere [3]
Today, developers consider many software patterns, especially those in analysis, as templates. In [4], Peter Code has defined patterns in briefly as following: A pattern is a template of interacting objects, one that may be used again and again by analogy. Simply speaking, the pattern extracted from a specific project can be integrated into an appropriate abstraction level such that it can be used to model and design the same problem or task, in a wide range of applications and domains. Based on this, experts consider the abstracted patterns as a template, which are usable through and by analogy.
As an example of this approach (Figure 1), shows the class diagram of the Resource Rental pattern [5], which forms the abstract template of the Resource Rental problem. The main objective of the pattern is to provide a model that can be reused to model the problem of renting any resource; therefore, the class diagram does not tie to the renting of a specific resource. Figure 2 shows an example of using the Resource Rental pattern in the application of the library services [5]. Simply through an analogy, one can apply the original abstract pattern into specific applications.More obstacles and impediments make the scenario much more difficult for a pattern developer because both the analysis and design patterns developmental process tend to be separate fields of study.
Though using analysis pattern through the process of analogy might appear to be a straightforward and simple technique for maintaining a good level of generality for the pattern, this technique, nevertheless, raises some important and critical problems that should be further investigated. These problems as follows:
It generates untraceable systems. Once the analysis pattern templates have been instantiated in the developed system, the original patterns will be no longer extractable. For example, consider the instance of the Resource pattern shown in Figure 2 and imagine it as part of a complete library service system. It would be very hard if not impossible, to extract the original pattern, shown in Figure 1, after such instantiation.
It Complicates system maintainability. Software maintenance is one of the costliest phases in the system development life cycle; therefore, any design that complicates system maintainability tends to inflate the cost even higher. One can imagine a very simple situation where the developed system documentation needs to be updated, due to some modifications in the system requirements. Since the developed system employs several patterns in its developmental phase, identifying the patterns to which the changes should be applied will always be tedious and time consuming.
It Trivializes classes roles of the pattern. To better illustrate this critical issue, we will use an example from [5], where a class diagram for designing a computer repair shop, is used by analogy to build the class diagram of hospital registration project. Instead of a shop that fixes broken computers, we have a hospital that fixes and cures sick people. Therefore, we can simply replace the class named computer in the first project, by the new class named patient in the next project. Even though such analogy seems achievable, it is highly impractical. There is a perceptible difference between the computer as a machine and the patient as a human. These two classes might look analogous, since they both have problems that need a fix; however, their behavior within the system is completely different. The role of the computer class is completely different from that of the patient. Hence, such analogy is highly inaccurate. There would be even more differences and discrepancies, if we tried to generate the dynamic behaviors of these two systems by using an analogy, as suggested in [5]