Criticism on Abstract Factory

Abstract Factory:
1. Intent:
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

I think, Intent is very important in patterns, which gives meaning of value to achieve the objectives and makes things easy to understand.

2. Also known as:
Kit.

I am in favour of also known as, because the reader should know it by all the names so that it can be taken in use as many ways as possible.

3. Motivation:
To my believe motivation plays an important part in patterns and in real life. For example, all the comfort in the form of invention like television, satellite, videos, tape recorders, vacuum machines, cookers, are a result of someone’s motivation.

That’s the main reason. I am in favour of motivation.

4. Applicability:
Define the applicability is very important because without knowing it, it can be brought in our lives. It is like a commercial of a product. Until you don’t believe that it is good for you, until you don’t know that thing exists, you can’t accept it, so applicability place very important role in real life.

5. Structure:
Whenever you buy a product from outside, you get a manual with that product that basically tells you how to use it. Sometimes manuals are just dictated and sometimes a manual with pictures on it but lacks of information.

I am in favour of step-by-step instructions with the snapshots that makes user to handle things easily without wasting time. When user go through these kinds of manuals, product are very easy to use without making any mistake.

6. Participants:
I am also in favour of participants and to prove myself, I can give an example of an ERD where all the entities are created in their own field where something is unique ID, and other fields do their own jobs and if we use them same way or if we don’t differentiate, then the functions will not work properly, so participating these entities are as important as different from each other, easy to understand and access.

7. Collaboration:
I am in favour of collaboration. For example, the Java Virtual Machine runs with collaboration of other operating systems. If this collaboration is missing, it will be impossible to run the operating system by the users and hard to update.

8. Consequences:
I am in favour of Consequences. A good example can be like whenever you log off from your computer account, all your profile and settings get close. On the same computer when another user logs on, he can’t see what you been doing. So basically, it changes the whole profile of the user which is not possible without the abstract factory.
In abstract factory, all the elements work together to give you one result. A best example to understand this thing is a car. All the systems of the car work as an element. As a result, the car moves and does whatever the driver likes. Abstract factory works in the same format.

In above paragraph, I mentioned an example of a car. Everything that has been created by the manufacturer, works in a same way it has been created. It moves and takes you to your destination but if you want to add something new in that car, you can’t. Let say, if you want the car to fly, you can’t add that option in the car once it has been made, because this car has been made to run on the road.

9. Implementation:
I am 100% in favour of implementation because all the research and your imagination you have gone through can be described under the implementation. It is the final stage of any research where you find out the drawback or how much your project is capable or successful because researcher creates something, he can’t think as a user but when he implements his project, user can give him an idea to make his product more robust.

10. Sample code:
I think, simple code is required separately because when a programmer comes and reads it, it will be more easy for him to understand it.

11. Known uses:
I am in favour of known uses. The good example of known uses is Win XP and Win Vista because the user has already used Win XP. For them, migration towards Win Vista is not a big deal. They already know most of the uses. Items and the elements of Win XP are same as Win Vista.

12. Related Patterns:
I am in favour of related patterns. For example, Nokia has its own N series phones. They can only be beaten by PDA phones like MDA Vario because they include both pocket PC and phone but these both do the basic same function that is making phone calls and sending and receiving SMS.

Reference:
Pages 124-132, Design Patterns CD Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Addison-Wesley 1998).

Abstract Factory Pattern

Abstract Factory Pattern:
A software design pattern, the Abstract Factory Pattern provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software would create a concrete implementation of the abstract factory and then use the generic interfaces to create the concrete objects that are part of the theme. The client does not know (nor care) about which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from its general usage [1].

For example, a user is using a computer system. He is not aware of different processes taking place in it. RAM is designed to function in its own way in contrast to other parts of the system. Behind, there are different logics running but for the user, it is only a single click away before his job gets done within seconds.

Reference:

[1] http://www.answers.com/topic/abstract-factory-pattern

Strategy Pattern

Strategy pattern:
Strategy pattern is an exacting software design pattern in which algorithms can be chosen to implement while in running mode. It is beneficially used in those cases where it becomes needy animatedly to switch the algorithms within the same software. Its main job is to provide or give the understandable meaning to identify a family of algorithms, put each one of them in a nutshell as an object that result them interchangeable. Another job it does is let the algorithms show a discrepancy independently from clients that use them [1].

For example, whenever you want to add, remove, or change any of the performance as such it is a very easy task because each one is its own class. Each of these actions or algorithm encapsulated into its own class is called strategy pattern [2].

References:
[1] http://www.answers.com/strategy%20pattern
[2] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPattern.htm

Adaptor Pattern

Adaptor Pattern:
According to The Gang of Four (GoF) “Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.”

When we develop the coding with the help of object-oriented programming languages, it tends to happen that we end up using a class that is unavailable within the active classes within the system. In this case, it is advisable to create an adaptor (also known as wrapper). This adaptor should be capable to be wrapped around the external class which will enable it to communicate with the existing class.

Reference:
http://www.c-sharpcorner.com/UploadFile/rajeshvs/AdapterPatternInCS11142005005135AM/AdapterPatternInCS.aspx.

Decorator Pattern

Decorator Pattern:
The Decorator Pattern is used for adding additional functionality to a particular object as opposed to a class of objects. It can be easy adding functionality by entire class objects of by subclassing an object you can try single objects this way and leave other like unmodified. Also decorator pattern is known as wrapper which the object interface identical to an object decorator can add and remove object without client realizing Decorator in a situation where you want to change the behaviour of an object repeatedly (by adding and subtracting functionality) during runtime.

Reference:
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/DecoratorPattern.htm

Anti-patterns

An anti-pattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences [1].

If a pattern represents a “best practice”, then an anti-pattern represents a “lesson learned.” Initially proposed by Andrew Koenig in the November 1995 C++ Report, there are two notions of "anti-patterns [2].”

1. Those that describe a bad solution to a problem which resulted in a bad situation.
2. Those that describe how to get out of a bad situation and how to proceed from there to a good solution.

People think that the presence of patterns are really important in successful development of a system which is right but in the meanwhile the presence of anti-patterns make that system robust which is not being accepted and considered at a wider scale.

Writers Brown Malveau, McCormick and Mowbray wrote a book called Anti-Patterns in which they spoke about refactoring software, architectures, and projects in crisis. It is their aim to go one step beyond to recommend a course of action for alteration, recuperation, and prevention [2].

They show us how to turn lemons into lemonade and how to avoid subsequent lemons, leading us away from the misfits of anti-patterns, and back towards the patterns that resolve them [2].

References:
[1] http://www-128.ibm.com/developerworks/webservices/library/j-bitterjava/index.html
[2] http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html#KindsOfPatterns