Professional Documents
Culture Documents
Design Patterns are already defined and provides industry standard approach to
solve a recurring problem, so it saves time if we sensibly use the design pattern.
There are many java design patterns that we can use in our java based projects.
Using design patterns promotes reusability that leads to more robust and highly
maintainable code. It helps in reducing total cost of ownership (TCO) of the
software product.
Since design patterns are already defined, it makes our code easy to understand
and debug. It leads to faster development and new members of team understand it
easily.
Creational
Structural
Behavioral
Creational Design Patterns
Creational design patterns provide solution to instantiate a object in the best possible
way for specific situations.
Singleton Pattern
Factory Pattern
Abstract Factory Pattern
Builder Pattern
Prototype Pattern
Structural Design Patterns
Structural patterns provide different ways to create a class structure, for example using
inheritance and composition to create a large object from small objects.
Adapter Pattern
Composite Pattern
Proxy Pattern
Flyweight Pattern
Facade Pattern
Bridge Pattern
Decorator Pattern
Behavioral Design Patterns
Behavioral patterns provide solution for the better interaction between objects and
how to provide lose coupling and flexibility to extend easily.
Template Method Pattern
Mediator Pattern
Chain of Responsibility Pattern
Observer Pattern
Strategy Pattern
Command Pattern
State Pattern
Visitor Pattern
Interpreter Pattern
Iterator Pattern
Memento Pattern
Singleton pattern is one of the simplest design patterns in Java. This type of design pattern
comes under creational pattern as this pattern provides one of the best ways to create an
object.
Singleton pattern restricts the instantiation of a class and ensures that only one instance of
the class exists in the java virtual machine.
The singleton class must provide a global access point to get the instance of the class.
Singleton pattern is used for logging, drivers objects, caching and thread pool.
SINGLETON PATTERN
This pattern involves a single class which is responsible to create an object while making
sure that only single object gets created.
This class provides a way to access its only object which can be accessed directly without
need to instantiate the object of the class.
Implementation:
create a SingleObject class. SingleObject class have its constructor as private and
have a static instance of itself.
SingleObject class provides a static method to get its static instance to outside world.
SingletonPatternDemo, our demo class will use SingleObject class to get
a SingleObject object.
Create a Singleton Class. public class SingleObject {
//illegal construct //Compile Time Error: The constructor SingleObject() is not visible
//SingleObject object = new SingleObject();
In Factory pattern, we create object without exposing the creation logic to the client and
refer to newly created object using a common interface.
Factory design pattern is used when we have a super class with multiple sub-classes
and based on input, we need to return one of the sub-class.
This pattern take out the responsibility of instantiation of a class from client program to
the factory class.
Above class diagram depicts a common scenario using example
of car factory which is able to build 3 types of cars i.e. small,
sedan and luxury. Building a car requires many steps from
allocating accessories to final makeup. These steps can be
written in programming as methods and should be called while
creating an instance of a specific car type.
Facade pattern hides the complexities of the system and provides an interface to
the client using which the client can access the system.
This type of design pattern comes under structural pattern as this pattern adds an
interface to existing system to hide its complexities.
This pattern involves a single class which provides simplified methods required by
client and delegates calls to methods of existing system classes.
Mediator pattern is used to reduce communication complexity between multiple
objects or classes.
This pattern provides a mediator class which normally handles all the
communications between different classes and supports easy maintenance of the
code by loose coupling. Mediator pattern falls under behavioral pattern category.
We can demonstrate mediator pattern by example of a chat room where multiple
users can send message to chat room and it is the responsibility of chat room to
show the messages to all users.
We can create two classes ChatRoom and User. User objects will
use ChatRoom method to share their messages.
Mediator design pattern is used to provide a centralized communication medium
between different objects in a system.
Mediator design pattern is very helpful in an enterprise application where multiple
objects are interacting with each other. If the objects interact with each other
directly, the system components are tightly-coupled with each other that makes
maintainability cost higher and not flexible to extend easily.
Mediator pattern focuses on providing a mediator between objects for
communication and help in implementing lose-coupling between objects.
Air traffic controller is a great example of mediator pattern where the airport
control room works as a mediator for communication between different flights.
Mediator works as a router between objects and it can have it’s own logic to
provide way of communication.
import java.util.Date;
public class ChatRoom {
public static void showMessage(User user, String message){
System.out.println(new Date().toString() + " [" + user.getName() + "] : " + message);
}
}
This pattern describes a way of building software from a group of components that
collaborate by passing a stream of information.
Information flow between components is a one-way serial stream of data.
Each component knows nothing about any other component.
Model - Model represents an object or JAVA POJO carrying data. It can also have
logic to update controller if its data changes.
View - View represents the visualization of the data that model contains.
Controller - Controller acts on both model and view. It controls the data flow into
model object and updates the view whenever data changes. It keeps view and
model separate.
Separation of Model from View components makes it possible to implement several
user interfaces that reuse the common core business logic.
Duplication of low-level Model code is eliminated across multiple UI
implementations.
Decoupling of Model and View code results in an improved ability to write unit
tests for the core business logic code.
Modularity of components allows core logic developers and UI developers to work
simultaneously without affecting the other.
Model
Manages the app data and state
Not concerned with UI or presentation
Often persists somewhere
Same model should be reusable, unchanged in different interfaces
View
Present the Model to the user in an appropriate interface
Allows user to manipulate data
Does not store any data except to cache state
Easily reusable & configurable to display different data
Controller
Intermediary between Model & View
Updates the view when the model changes
Updates the model when the user manipulates the view
Typically where the app logic lives
This pattern decouples changes to how data are manipulated from how they are
displayed or stored, while unifying the code in each component. In other words, it's
a way of developing apps keeping the data (model) used in the program, and the
visual (view) component of the program separate from one another, each
interacting only with a controller containing the logic of our program. The view and
the model interact only with the controller NEVER with each other.
A triad of three modules linked by the Observer Pattern. The View drives a
presentation and elements within the View observe the Model. Elements within the
Controller observe the View and Model, and elements within the Model observe
the Controller.
In a simple application, the Controller can affect changes to the Model based on
user input and also communicate those changes to the View so that the UI can be
updated.
In real-world applications, however, the View will normally also need to update to
reflect additional changes to the underlying Model. This is necessary because
changing one aspect of the Model may cause it to update other dependent Model
state.
The Observer Pattern is a specific instance of the publish/subscribe paradigm.
These techniques define a one-to-many dependency between objects such that a
publisher object can notify all subscribed objects of any state changes without
depending on them directly.
In proxy pattern, a class represents functionality of another class. This type of
design pattern comes under structural pattern.
Proxy pattern intent is to “Provide a surrogate or placeholder for another object to
control access to it”. The definition itself is very clear and proxy pattern is used
when we want to provide controlled access of a functionality.
In proxy pattern, we create object having original object to interface its
functionality to outer world
A proxy object acts instead of some other object or objects. It fields requests,
passing them on as necessary.
Layers pattern, sometimes called tiers, is a classic pattern that is used in many
systems. This pattern divides a software system into hierarchical layer.
N-layers of application may reside on the same physical computor(same tier) and
the components in each layer communicates with the components of other layer by
well defined interfaces.
Layered architecture focuses on the grouping of related functionality within an
application into distinct layers that are stacked vertically on top of each other.
Communication between layers is explicit and loosely coupled.
With strict layering, components in one layer can interact only with components in
the same layer or with components from the layer directly below it.
The blob is a bad structure- an anti-pattern. All ths classes in the program are
merged into one large class. There is structure in terms of constituent methods, but
that is all.
There is no large-scale structure. The blob is what someone would create if they
did not really understand what OOP is about – or if they could not see how to
structure the software into meaningful classes.