Traditional Design Patterns

[15] Analyzing Pitfalls to Seek a Permanent Solution

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

& G. K. Srikanth, IJOP, IJSA, IJSR Sr. Editor

In the above columns we highlighted fourteen of the major problems that are believed to diminish

the strength of the role of patterns in developing software systems.

 

CONCLUSIONS 

Pattern development poses several unique challenges to the pattern developers, like the ones clearly highlighted in the previous columns. These challenges tend to diminish the strength of the role of patterns in developing software systems, subsequently contributing to the ineffectiveness of patterns. Probably, nothing can be as damaging as misusing the term experience while attempting to design and write patterns; in fact, this misplaced feeling or perception could severely dent the quality of the developed patterns. Another curious problem does occur in the realm of creating a large number of pattern, when most of them represent and deal with almost the same problem. Frequent duplication of efforts in writing patterns will also make it very cumbersome to devise a common vocabulary for pattern development. Novice and fresh developers of patterns may also get confused while selecting the right and appropriate pattern for a pool of candidate patterns; in many cases, inexperienced pattern developers lack the knowledge of clear guidelines.

Pattern designers also face the piquant situation of differentiating between analysis and design patterns, while there is an immediate need for developing patterns that are easy to understand and comprehend so that one can ensure and ascertain quicker adoption in practice. Another vital string in the earlier series provides criticality of developing patterns to focus on specific patterns defined with clear boundaries. This column also raises another peculiar situation of developing patterns that solve a collection of problems that finally results in large-scale patterns with very limited applicability.

Patterns also display certain specific compositions that integrate and sew together different patterns of the similar type (i.e. design patterns, analysis patterns, etc) to build and design larger components or different types of patterns that also include process patterns, managerial and organizational patterns and other types of patterns. In many cases, existing patterns lack proper connectivity across both analysis, design developmental phases, while they can also become untraceable, and lost without providing clear guidelines and rules for traceability. Patterns can also become obsolete because of drastic changes in technology or by the fact that the original problem the pattern devised to sole is no longer in usage. Most of the patterns are modeled very poorly, affected by nagging problems like dangling classes, the use of accessory methods, classes that are useless in performing meaningful functions, classes without inheritance and aggregation and with presence of a number of passive objectives.

In addition to the above mentioned problems, very poor patterns show relationship without any unique names, and under such a scenario, sundry relationship are yet to be fully decomposed as one-to-many relationships. Ultimately, patterns community and design forums suffer from the tendency of reinventing the wheel syndrome, as patterns themselves are not included in the final software product and developers come upon mixed results when attempting to deduce the patterns from the models. These are some of the most important pitfalls while designing a pattern and one may need to conduct advanced research to integrate patterns like designing and testing and integration must encourage a coherent composition of several important parameters. In the future, upcoming columns, we will attempt to introduce a novel thinking of software patterns as a way to confront the problems we have discussed so far in the earlier columns.

In conclusion, before the patterns community can more effectively utilize patterns in practice, the fourteen problems or pitfalls discussed in this blog must be confronted. Further research much be done into the process of integrating patterns, such as design and testing, into a coherent composition.

In the next set of columns, we will introduce our novel thinking of software patterns as a way to confront the problems we have discussed so far.

 
  

 

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