You are on page 1of 38

IT323 Software Engineering

 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 is one of the Gangs of Four Design patterns.

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 {

//create an object of SingleObject


private static SingleObject instance = new SingleObject();

//make the constructor private so that this class cannot be


//instantiated
private SingleObject(){}
//Get the only object available
public static SingleObject getInstance(){
return instance;
}

public void showMessage() {


System.out.println("Hello World!");
}
}
Get the only object from the singleton class.

public class SingletonPatternDemo {


public static void main(String[] args){

//illegal construct //Compile Time Error: The constructor SingleObject() is not visible
//SingleObject object = new SingleObject();

//Get the only object available


SingleObject object = SingleObject.getInstance();

//show the message


object.showMessage();
}
}
 Probably the simplest and most obvious pattern. It describes the situation where
one class uses another.
 Delegation is a more general way of extending the functionality of a class.
 Factory pattern is one of the most used 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.

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

You might also like