Design Patterns in OOPs

Introduction:


For starting with Design Patterns, pre-requiste is one should aware with the Object oriented concepts.

Here, we will try to simplify the term and purpose of the Design Pattern.

First normal and very common query could be, What is Design Patterns, why they are used?

In a simple layman term, a design pattern is a general reusable solution to a commonly occurring problem in software design.

Defining Design Patterns more descriptively...

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code.

It is a simply a description for how to solve a problem that can be used in many different situations.

Design patterns is used to speed up the development process by providing tested, proven development methods or paradigms. Effective software design requires considering issues that may not become visible until later in the implementation.

Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.
Digging into depth,
Design Pattern is categoried in three different sub patterns.

Creational Patterns
Structural Patterns
Behavioral Patterns.

Creation Patterns
This design pattern is all about class instantiation.

This pattern can be further divided into class-creation patterns and object-creational patterns.

Abstract Factory : Creates an instance of several families of classes
Factory : Creates an instance of several derived classes
Builder : Separates object construction from its representation
Prototype : A fully initialized instance to be copied or cloned
Singleton : A class of which only a single instance can exist

Structural patterns
This design patterns is all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality.

Adaptor : Match interfaces of different classes
Bridge : Separates an object’s interface from its implementation
Decorator : Add responsibilities to objects dynamically
Facade : A single class that represents an entire subsystem
Proxy : An object representing another object

Behavioral patterns
This design patterns is all about Class's objects communication. Behavioral patterns are those patterns that are most specifically concerned with communication between objects.

Chain of responsibilty : A way of passing a request between a chain of objects
Command : Encapsulate a command request as an object
Interpreter : A way to include language elements in a program
Iterator : Sequentially access the elements of a collection
Observer : A way of notifying change to a number of classes
State : Alter an object's behavior when its state changes
Visitor : Defines a new operation to a class without change

Now we will pick the popular and commonly used design pattern and explain in detail.
Staring with the Factory Pattern.

What is a "factory" and why would you want to use one?
A factory, in this context, is a piece of software that implements one of the "factory" design patterns introduced . In general, a factory implementation is useful when you need one object to control the creation of and/or access to other objects. By using a factory in RMI, you can reduce the number of objects that you need to register with the RMI registry.

Examples of Factories in the Real World:
The Bank
The Library
These two example is sufficient to understand the actual process of the Factory Patterns. These examples are from the real life.

Let's take the example, commonly illustrated in the text book, GoF.
Widgets in a GUI Environment.
This example explains , how an Abstract Factory can be used to create widgets for a GUI environment. By designing the client to use the Abstract Factory interface, different factories can be created to generate different sets of widgets without requiring changes to the clients. This example is not intended to illustrate a useful implementation of Abstract Factory, as Java's AWT and Swing do the work for you, but it does show how easily design patterns can be implemented in RMI.
One other point to notice is how the pattern is split between client and server. This split was arbitrarily chosen, and with RMIs object-oriented nature you could decide to make the split in the pattern elsewhere.

In General , this pattern consists of two class hierarchies, one of Products, and one of Creators. Each ConcreteCreator class creates instances of specific ConcreteProduct classes using a factory method.

The factory pattern can help solve your application issues. For example, developers often must reply to users based on each user’s machine, creating multiple hardware issues. The factory pattern can streamline the process. The concept is simple, but the solutions created with the factory pattern are powerful.

For more understanding, let's take one more example.
Communications breakdown
Consider the example of a data collection application where various field devices supply data to the application via TCP/IP sockets. The application was originally written to communicate with one device but was expanded when the company produced a newer version. Unfortunately, this new hardware did not speak the same language as the previous version. Marketing required the application to support both hardware versions, since customers might buy new units and install them in tandem with older units. The factory pattern eased the burden of supporting multiple device types.

In short and effective explanation of fatory pattern is :
=> if we have a super class and n sub-classes, and based on data provided, we have to return the object of one of the sub-classes, we use a factory pattern.

Now, we will focus on the positive and negative points on using the Factory Patterns.
Positives:
-Eliminates the need to bind application-specific classes into your code
-Provides hooks for subclassing. Creating objects inside a class with a factory method is always more flexible than creating an object directly. This method gives subclasses a hook for providing an extended version of an object.
-Connects parallel heirarchies. Factory method localises knowledge of which classes belong together. Parallel class heirarchies result when a class delegates some of its responsibilities to a separate class.
Negatives:
-Clients might have to subclass the Creator class just to create a particular Concreate object.