Traditional Design Patterns

[14] Reinventing the Wheel: An Undesirable and Dangerous Development

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

” A pattern is a plan, rather than a specific implementation.” [1]. Pattern developers never directly use

design patterns to guide programming. They are guides for modeling purposes. A pattern is “an

attempt to describe successful solutions to common software problems.” [2].

“Design patterns represent solutions to problems that arise when developing software within

a particular context” [3]. However, how does one follow the patterns to find specific solutions for a given problem?

By instantiation, concrete objects from the specific problem will replace the original abstract objects in patterns. The obvious result is the pattern instances, which are the models for the specific problem and a specific guide for programming. The process of applying patterns is in figure 1.

In the example of the current Design Patterns Approach, Design Patterns (d-models) and their instances (i-models) are always separate models. After instantiation, the instances are less abstract, less stable and inextensible, when compared to their patterns. However, we can see only the instances as the result of the Design Patterns Approach, in general practice. The resulting models will never be displayed in the patterns and the instantiation processes. By instantiating patterns within a particular problem context, the problem at hand is easily manageable; however, the stability of the pattern is totally lost in the final model. This causes a completely new set of problems.

PROBLEMS

  According to the definition, Design Patterns plan to facilitate the reuse of software architecture. Therefore, a well-designed pattern should be always stable and provide a strong foundation for reuse. To achieve this ultimate goal, Design patterns must be abstract, general and common in nature. This makes them unsuitable for detailed implementation on a specific problem. Thus, Design Patterns must be instantiated into pattern instances, specifically based on a specific problem context. This creates a pronounced discrepancy between the Design Patterns and the final specific pattern instances for the given problem. However, the instantiation process can work as a useful roadmap around this discrepancy. It is an efficient way to migrate from the existing knowledge to the product for a specific problem.

Nevertheless, currently, designers tend to discard this roadmap soon after using it. Generally, the description of this process is unavailable in the final models. This means

that it is possible to create a specific model employable for the given problem, but the capability to trace back to its blueprint and later extend the model in the future is missing altogether. The model loses its generality and abstraction soon after instantiation, causing it to be very weak in adaptability and extensibility. When developers want to extend the software at a later stage, they simply cannot directly reuse this model. They will have to reconstruct the whole model directly from the original patterns.

From a utilization perspective, Design Patterns are the rules of the road. The provided instances are the actual driving and the problem context is supposed to be different driving situations. The rules are always constant and uniform, although the actual driving may change under different circumstances. To drive safely and efficiently, people must learn the basic rules first and then apply them according to the different circumstances.

Every time they drive, they must keep the basic rules in mind, in order to adapt to different and varying situations. That is the important key to stable driving. However, in software modeling, unlike driving, people tend to discard the patterns they use, as soon as they get the desired result. They seldom describe the patterns and the instantiation process in the final models. This makes their results highly unstable and inextensible to different problem contexts. Expecting these models to be stable under future changes is similar to applying past driving sequence actions to different times and locations!

A pattern is definitely not the part of the final software product, though it acts as a powerful tool to find a solution for a specific problem, in a quick and accurate manner. However, the pattern is the only stable part you can apply repeatedly in modeling. The Systems Analyst and designer feed the patterns with a specific problem and get a specific model through instantiation. The final pattern instance is a specific solution to the given problem. In the current Design Patterns approach, all of the objects in the final model are very concrete and specific. It is usable as a programming guide. However, it is highly unstable and un-scale able, because of the same set of similar characteristics. For example, figure 2 is a design pattern on the sales transactions. Figure 3 is the instances of this pattern [Coad 1995].

As shown in these figures, there is no instantiation processes in figure 3, the result of modeling using the current patterns approach. Here, the patterns help to deduce instances, but the final model rejects and discards the patterns. From figure 2, it is very easy, simple and safe to deduct the “Picklist ” instance from ” Subsequent Transaction”, and keep all of its collaborations, based on the specific problem context. Nevertheless, in the other direction, from figure 3, it is very difficult and uncertain to induct ” Subsequent Transaction ” from ” Picklist “. Thus, a designer cannot work back to the original designs to extend existing models.

For example, if a new object named ” Plan list ”  is introduced in another situation, the information displayed in figure 3, is not sufficient to define the new ” Plan list ” object.

 

References

  1. Coad, D. North, and M. Mayfield. ” Object Models ” Strategies, Patterns, & Applications” Yourdon Press, Prentice-Hall, Inc. New Jersey. 1995.

  2. Schmidt 1996 Douglas C. Schmidt, Ralph E. Johnson, and Mohamed Fayad. Special Issue on Software Communications of the ACM, Vol. 39, No. 10, October 1996.

  3. David Levine and Douglas C. Schmidt. Introduction to Patterns and Frameworks. Department of Computer, Science Washington University, St. Louis. http://www.cs.wustl.edu/~schmidt/PDF/patterns-intro4.pdf

  4. Wu, H. Hamza and M.E. Fayad. Implementing Pattern Languages Using Stability Concepts, The sixth annual ChiliPLoP 2003, Carefree, AZ, March 2003.

 

Tags: ||Pitfalls in Traditional Software Patterns|| //