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.]

Strategy Pattern

[Blog 10]

The Strategy pattern is used to “define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.” [1]

Strategy pattern is used to reduce hard coding any algorithm into classes that will not always be used by them or the objects associated. Sometimes more than one algorithm might be needed, and if implemented in the class it will make maintenance of the program more complex. In order to prevent these problems, the strategy pattern creates classes that encapsulate those algorithms. Whenever an algorithm is need it is called or swapped with other functions to match the need of the interface.

Just think of an electric drill, it can be used to do a number of tasks just by changing the drill bits. For example, it can be used to make holes, screw, unscrew, hammer, and do wood work as well. The electric drill is the same at the end of the day, but its functions can be changed by swapping it with other functions.

The advantages of using strategy pattern are that the:

• different algorithms can be grouped under a common class and called whenever needed.
• New algorithms can be further added to expand the functionality of the interface
• Possibility of switching to algorithms at run-time
• The client can chose the algorithm needed without using a switch statement
• Where sub classing is not an ideal option, strategy pattern can be used instead

The disadvantages of strategy pattern is that the:

• The application must know all the strategies that are available
• There will also be more objects [2]

I think Strategy pattern is a very useful pattern as it allows a pool of functions to be available and called whenever needed. There is no need for inheritance to occur to inherit functions. And also this allows expansion of the system very easily.

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.

Adapter Pattern

[Blog 9]

Adapter Pattern is used to convert the interface of one class to another so that it meets the requirements of the client. Adapter pattern solves the problem of incompatible interfaces of classes that need to work together. Usually, the interfaces are fixed without modifying the objects and classes directly. The adapter pattern is also known as “Wrapper”. [1]

The wrapper object is known as the Adapter and the object it wraps is referred to as the Adaptee. [2]

In some situations, reusable classes cannot be really be reused because of unpredictable situations like change in program structure after a period of time that makes the class incompatible with new classes.

A real life example is of a European type plug being fitted to an American type power socket which will not work obviously because they have different connections/interfaces which make them incompatible. In order for them to work with each other, a converter needs to be fitted, that converts the plug to adapt to the socket.

There are two kinds of adapters, namely, class adapter and object adapter. A class adapter changes the adaptee in such a way so that it conforms to the interface required but unfortunately, this does not work when the subclasses have to be adapted as well as they have their own characteristics. Since the adapted is derived from the adaptee, the adapted can override its activities.

Object adapters are simpler, as they allow the adapter to work with both the object and the sub-classed objects. So functions can be added to the object class and the sub classes as well. Unfortunately, because sub class objects have their own characteristics, overriding the adaptee’s behaviour is difficult as it would require each sub class object to be considered first. Finally, adapters have the ability to have some of their own functions, which gives the ability of adding functionality. The disadvantage of adapters is that extra lines of codes have to be added and maintained.

It should be noted that object adapters use object composition whereas class adapters use inheritance. [3]

References:
[ref.1] - Design Patterns for Dummies, by Steve Holzner, Wiley Publishing Inc., 2006, ISBN: 978-0-471-79854-5 pp.121

[ref.2] - Software Architecture Design Patterns in Java, by Partha Kuchana 2004, ISBN 0-8493-2142-5, ch.20, p.213.

[ref.3] - Design Patterns for Dummies, by Steve Holzner, Wiley Publishing Inc., 2006, ISBN: 978-0-471-79854-5 pp.134

Facade Pattern

[Blog 8]

Facade pattern is a bit similar to adapter pattern. The façade pattern makes the Object Oriented interface easier to use. According to the Gang of Four, the façade pattern “provides a unified interface to a set of interfaces in a sub system. It defines a higher-level interface that makes the sub system easier to use”. [1]

Façade is used when unsuccessfully trying to rewrite a code which was supposed to be simpler. And so, the façade pattern acts as a “skin” on top of the original one, and when the original coding changes the façade pattern has to be changed as well. [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 for Dummies, by Steve Holzner, Wiley Publishing Inc., 2006, ISBN: 978-0-471-79854-5 pp.134