Monday, 14 May 2007

ANTI-PATTERNS

CRITIQUING PATTERNS (Position of Anti-patterns within computing.)

Hype is something deliberately misleading or deception; exaggerated or extravagant claims made especially in advertising material. To ravage is to bring heavy destruction or grievously damage something. Business Process Reengineering is a management approach aiming at improvements by means of elevating efficiency and effectiveness of the processes that exist within and across organizations. Yes it is possible that goods things could be destroyed but not all and not always. For anything to be” ravaged”, there has to be a reason. If a scenario is all good, then there is no reason and cause to be hyped. From the above quotation, BPR is wide subject hence almost everyone can write about it. Almost every specialty and field deploys BPR. That’s the reason as to why many people from different circles have to write about it portraying what they understand about it. Relating this to patterns, every reader understands patterns in various ways. For example, when I had just started reading about them, I thought I understood them the very first time I had a lecture. I was wrong, each day that passes with further reading, proves to me that am still no where near the experts in patterns. If I wrote an article about patterns, it wouldn’t imply I don’t understand the basics about them! Any one who writes about BPR definitely knows something about them and criticizing another person’s work should be given credit for at least reading it and expressing his opinion about it for it is through criticisms that we improve and bring out the best from our selves.

To say antipatterns are hype as the author states, we need to understand what they are. Anti-patterns show something that looks like a good idea, but which backfires badly when applied. Therefore they are a toolkit for categorizing, identifying and getting rid of the typical problems in the software development process showing how to go from a bad solution to a good solution. With so many people writing about them in various ways, despite their importance in the computing world, is it right to criticize them? As mentioned above, we all understand situations in different ways. With a number of professionals seeing a bottle half full and others half empty, what the writer of this quotation calls hype isn’t really one to me.

The quotation goes ahead to say. “Every author has the responsibility to convey good and valuable information to its readers.” If this is the case then anti-patterns shouldn’t be criticized. We the readers of anti-patterns get vital information which helps in overcoming the “traps and pitfalls” which might cause us failure during the software engineering process. With work compiled over 40yeas ago as the author states, computer technology has evolved from time to time. This also means patterns need to change since it is the same field where they are applied.
AntiPatterns are quite closely related to design patterns and we would not be wrong to call them natural extensions to Design Patterns. With such a close relationship, it is not a mistake that anti-pattern authors had something to write about. Anti-patterns are not hype! They show how an antipattern comes into existence, what causes it, how to avoid them and the solution to them with any related solution as a reserve. In the first paragraph we saw that hype is something deliberately misleading or deception; exaggerated or extravagant claims made especially in advertising or promotional material. Anti pattern authors don’t exaggerate or make extravagant claims because they do not carry out advertisements. They warn us to be aware of the possible traps and pitfalls which would be disastrous during the software development process.



The book writes about patterns showing how wrongly they are applied. If this book is called “traps and pitfalls”, it would be misleading to its buyers and intending readers for it wouldn’t show traps and pitfalls to what situation.
By calling it anti-patterns, the name suits it as the reader would know what it’s about and where to apply the knowledge got from it. Right from the beginning the book shows the metamorphosis of the anti pattern as discussed below;
Antipattern Name which defines the problem that requires a solution, in an informative way. From this we get the context and cause which call for a solution in this case being the Antipattern solution. AntiPattern Solution showing how the applied solution becomes the bad solution/ Antipattern. This comes with symptoms, and consequences which come about as a result of applying this Antipattern solution. Refactored Solution the best solution to the original problem that should have been applied in the first place. It shows positive consequences and benefits after it is applied.



References
[1] Brown William J. et al. Anti Patterns –
Refactoring Software, Architectures, and Projects in Crisis.
John Wiley & Sons,
3rd March 2007.

[2] Brown William J. et al. Anti Patterns (the official website) [in HTML format]

[3] Gamma Erich et al. Design Patterns
Elements of Reusable Object
Oriented Software.
Addison-Wesley,
April, 2007

[4] http://www-128.ibm.com/developerworks/webservices/library/ws-antipatterns/

No comments: