Conclusion on Patterns

Pattern was a very interesting subject to learn. I did OOP before but did not know that there are other ways of developing software like pattern oriented development. It was fun learning so many patterns, sometimes confusing. But with group discussions, class works and sometimes having to present our classwork in front of the class was very interesting. Now i know what pattern is and where it stands in the software development world.

At the beginning we all started with the general Christopher Alexander's building construction idea and then moved on to learn how it was adopted in the software world and why.

Several different patterns brought several advantages that can be used to address particular problems like avoiding class explosion, undesirable inheritance, hard coding each and every object, non extensibility. All these problems were addressed with a particular pattern and the good thing is sometimes patterns tend to look very similar and therefore understanding was not difficult at all as the differences became clear during lectures.

We finished with anti-patterns, which was also a very interesting topic. Now i understand the role of anti-pattern as well. We had to do a lot of reading but it was fun.

To summarise these are the 23 GoF patterns














Source of table: Design Patterns CD, Elements of Reusable Object-Oriented Software, By Erich Gamma et al. , Addison Wesley Longman, Inc.

So this is it, we completed patterns, a Very Big Thank You to Dr. SRI who made every effort to complete the course and answer all our questions, ask us so many questions and gave us so much trouble by making us argue with each other in the class so that we understand each and every topic.
And I thank all those who commented on my blog and good luck to everyone.

Anti-Pattern

[Blog 13]

From my understanding, an Anti-pattern is a bad solution that is applied to a recurring problem. This happens when a developer applies an inappropriate solution to a problem thinking that it is the correct one or the solution appear to be the right one.

Anti-patterns are also called “pitfalls” meaning "drawbacks". They are groups of commonly-reinvented bad solutions to problems. Anti-patterns form a class which is studied to prevent the same mistakes from happening again. [1]

Repeating mistakes are recorded in a structured manner, thus when they occur it becomes easier to recognise them and also helps systems that are affected to recover from those mistakes. Programmers should make every effort possible to avoid and eliminate anti-patterns as soon as they are detected.

Anti-pattern extends the scope of design patterns research into more interesting areas like Refactoring (improve the structure of the code without changing the functionality of the application), Reengineering, System Extension, and System Migration. [2]

I think anti-pattern is important as it helps to improve patterns. Mistakes that happen in patterns are not recorded in a structured manner, instead they are just updated with a newer, better solution and so it is very difficult for developers to see unfit patterns and solutions. The grouping of wrongly applied solutions are grouped in anti-patterns and this allows pattern users to see what is wrong and how it can be changed.
I think it should coexist with patterns.

References:
[ref.1] - http://en.wikipedia.org/wiki/Anti-pattern

[ref.2] - http://c2.com/cgi/wiki?WhatIsRefactoring

Bridge Pattern

[Blog 12]

The Gang of Four described the Bridge pattern as one used to “decouple an abstraction from its implementation so that the two can vary independently”. Bridge pattern dissociates the abstraction from the implementation and allows the implementation to be selected when the program is run. This also allows the abstraction and the implementation to be modified independently whenever needed. It also reduces the amount of sub-classes in programs. [1]

References:

[ref.1] - Design Patterns CD, Elements of Reusable Object-Oriented Software, by Erich Gamma et all, Addison Wesley Longman Inc.

Decorator Pattern

[Blog 11]

A Decorator Pattern is one which allows more functions to be attached to an object in a flexible manner. [1] Functionality can be added without the need to subclass an object. The Decorator Pattern is also known as “Wrapper”. Unlike sub-classing, the decorator pattern allows the additional functionality to be added only to the object that is desired. With inheritance, if a function is added, then every sub-class will have that function which is not always desirable.

A real life example might be a Vehicle object having a special functionality of loading and unloading a wheelchair and another normal vehicle that does not need that functionality. If that function is inherited through the main vehicle class then every vehicle will have that feature which will not always be needed.

A software example might be a function to change the font type of text in a document which is applicable where text is used and which is not applicable in other situations for example, where images are used.

The big advantage of using decorator pattern is that the decorations/ functions can be added anywhere where the decorator is defined. That is, if the decorator pattern is associated to a pool of functions or appearance of an interface, then it can be applied to any object that might need the functions which are subclasses of the decorator class.
Moreover, the existing structure of the coding is not affected as decorator classes and functions are separate and can be added or removed during execution. And when applied to objects, only affect the object targeted and not other objects. Also, when sub-classing is not very suitable like in cases where classes are sub-classed again and again to add functionality, the decorator pattern can be used to easily prevent this.
Decorator patterns are well known to be used in object-oriented user interface toolkits. [2]

References:
[ref.1] - Design Patterns CD, Elements of Reusable Object-Oriented Software, by Erich Gamma et all, Addison Wesley Longman Inc.].

[ref.2] - Design Patterns CD, Elements of Reusable Object-Oriented Software, by Erich Gamma et all, Addison Wesley Longman Inc.]