CSI3024

Software Application Architecture

By,
Dr.Swetha.N.G.,
Assistant Professor Senior,
Department of Analytics,
School of Computer Science and Engineering,
Vellore Institute of Technology, Vellore.

Email: [email protected] Mobile: 8903580808 Cabin: PRP 217-16

Module 2 - Java Patterns
GOF and JEE Blue Print Patterns, Creational, Structural and Behavioral
patterns, Modern Java EE Patterns, Core J2EE Patterns
(7 hours)

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
GOF
• Gang of Four (GoF) Design Patterns
• GoF Design Patterns refer to the 23 software design patterns presented in
the book "Design Patterns: Elements of Reusable Object-Oriented
Software", written by Erich Gamma, Richard Helm, Ralph Johnson, and
John Vlissides in 1994.
• These patterns provide solutions to common design problems in object-
oriented software development.
• They are categorized into three groups:
• Creational pattern
• Structural pattern
• Behavioral pattern
A. Creational Pattern 5

• Creational Design Patterns focus on the process of object creation in

software development.
• These patterns make sure that we create things in a way that’s not only
easy but also flexible, so we can change them later if we need too.
• They hide the complicated details of how we put pieces together.
• These patterns provide various object creation mechanisms, which
increase flexibility and reuse of existing code.
• Types of Creational Pattern
• Factory Method
• Abstract Factory
• Builder
• Prototype
• Singleton

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
1. Factory Method Pattern
• Factory Method is a creational design pattern that provides an
interface for creating objects in a superclass, but allows subclasses
to alter the type of objects that will be created.
• This pattern helps to decouple object creation from the client and
allows the client to create objects without knowing the exact class of
the object it needs.
• This enables more flexible and maintainable code, as it allows new
types of objects to be added without altering the existing code that
uses the factory.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Analogy
• Imagine you're ordering food at a restaurant.
• You don't need to know how the food is cooked, or how it’s
prepared; you just tell the waiter what kind of food you want, and
the waiter will bring it to you.
• The waiter is the factory.
• The food is the object.
• You, as the customer, don’t care about the cooking process (how the object is
created), you just care about the food (the object) being brought to you.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components
• Product: The type of object that the factory method will create.
• Concrete Product: It implements the Product interface.
• Creator: An abstract class or interface that declares the Factory
Method, which returns an instance of the Product.
• Concrete Creator: A subclass that implements the Factory Method to
create a specific instance of a Product.
• Client: The class that uses the Creator and its Factory Method to get
the product.
Eg: Create different types of documents (like PDF
and Word documents) using a factory method.
• Step 1: Define the Product interface.
• This represents the product that will be created by the factory method.

Thi s is a contract that all types of documents will follow (it will
defi ne a method to create the document).

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Eg: Create different
types of documents
(like PDF and Word
documents) using a
factory method.
• Step 2: Create
ConcreteProduct classes that
implement the Product
interface.
These are the specific types of documents we can
create (like PDF and Word).

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Eg: Create different types of documents (like PDF
and Word documents) using a factory method.
• Step 3: Define the Creator class with the factory method.
• The creator class defines the factory method, but does not implement it.
• It is left to the subclasses to implement the factory method.

The factory method will decide which document to create.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Eg: Create different types of documents (like PDF
and Word documents) using a factory method.
• Step 4: Implement ConcreteCreator classes that override the factory
method.

These classes will actually create the PDF or

Word documents when asked.
Eg: Create different types of documents (like PDF
and Word documents) using a factory method.
• Step 5: Client Code that uses the Factory Method
• The client interacts with the creator class, and it doesn’t need to know the
concrete type of object being created.
• It only needs to call the factory method, which is implemented by the
concrete creator classes.

The client can use the factory to get the document it needs
without knowing how the document is created.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Factory Method
• Flexibility in Object Creation: The client is decoupled from the exact
class it needs to instantiate, allowing for easier modification and
extension.
• Encapsulation: The object creation logic is encapsulated in the
creator class, making it easier to change or extend the object creation
process without modifying client code.
• Extensibility: New product types can be added easily by creating new
concrete creator classes, without altering existing client code.
• Adheres to Open/Closed Principle: The pattern allows classes to be
open for extension but closed for modification.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages of Factory Method
• Increased Complexity: Introducing factories can add complexity
when only simple object creation is needed.
• Subclassing Overhead: If the hierarchy of creators becomes too large,
it could lead to unnecessary complexity in the design.
When to Use the Factory Method
• When the exact type of object to be created isn’t known until
runtime.
• When a class has multiple subclasses, and you want to instantiate
one of them based on some criteria.
• When you need to manage object creation in a centralized and
flexible way.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
2. Abstract Factory Pattern
• The Abstract Factory Pattern is a creational design pattern that
provides an interface for creating families of related or dependent
objects without specifying their concrete classes.
• It is often used when there are multiple related products (e.g., UI
components like buttons and checkboxes for different platforms like
Windows and Mac).

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components
• Abstract Factory: Declares the methods that create abstract products.
• Concrete Factory: Implements the methods to create concrete
products.
• Abstract Product: Declares the interface for a product.
• Concrete Product: Implements the interface for a product.
• Client: Uses the Abstract Factory to create products, without needing
to know the specific classes that are created.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Analogy

• Imagine you're designing a car factory that produces cars.

• The factory produces sports cars and family cars, each with
different types of parts.
• Abstract Factory: A general factory interface that says, "I can make a car.“
• Concrete Factories: A sports car factory and a family car factory, each knowing
how to create specific parts like seats, wheels, and engines for their
respective car types.
• Products: The parts that the factory makes, such as a sports car seat and a
family car seat.
Example
• Create a graphical user interface (GUI) that can work on both
Windows and MacOS platforms. Each platform has its own versions
of UI components like Buttons and Checkboxes.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 1: Define Abstract Products

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 2: Create Concrete Products

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 3: Define the Abstract Factory
Example
• Step 4: Create Concrete Factories

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 5: Client Code

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Abstract Factory Pattern
• Flexibility: Easily add new product families by introducing new factories
and products.
• Consistency: Ensures that a family of related products is used together.
• Encapsulation: Hides the details of product creation from the client.
• You can be sure that the products you’re getting from a factory are
compatible with each other.
• You avoid tight coupling between concrete products and client code.
• Single Responsibility Principle: You can extract the product creation code
into one place, making the code easier to support.
• Open/Closed Principle: You can introduce new variants of products
without breaking existing client code.
Disadvantages of Abstract Factory Pattern
• The code may become more complicated than it should be, since a
lot of new interfaces and classes are introduced along with the
pattern.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
3. Builder Pattern
• The Builder Pattern is a creational design pattern used to construct
complex objects step by step.
• It allows for the creation of different types of objects using the same
construction process, but with different configurations or attributes.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components
• Builder: This defines the steps required to build the product and
provides methods to set each part of the product.
• ConcreteBuilder: This implements the Builder interface and
assembles the parts of the product.
• Product: This is the final object that is being built.
• Director: This orchestrates the building process, calling the builder
methods to construct the product.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Let's say you want to build a Computer object.
• A computer can have different components like CPU, RAM, storage,
etc.
• Using the builder pattern, you can create computers with different
configurations, like gaming PCs, office PCs, or budget PCs.
Example
• Step 1: Product
(Computer Class)

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 2: Builder Interface
• The ComputerBuilder interface defines the methods for constructing the
parts of the computer.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 3: ConcreteBuilder
• The GamingComputerBuilder implements the ComputerBuilder interface to
construct a gaming PC with specific parts.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 4: Director
• The Director class is responsible for constructing the product using the
builder.
Example
• Step 5: Client Code
• Finally, in the client code, you use the Director to create a specific
configuration of the computer (e.g., a gaming PC).

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of the Builder Pattern
• Separation of Concerns: The building logic is separated from the
client code.
• Flexibility: You can easily create different kinds of objects with varying
configurations.
• Readability: The code becomes more readable because complex
construction logic is encapsulated in the builder.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages of the Builder Pattern
• The overall complexity of the code increases since the pattern
requires creating multiple new classes.
4. Prototype Pattern
• Prototype is a creational design pattern that lets you copy existing
objects without making your code dependent on their classes.
• It enables object creation by cloning an existing object, known as
the prototype.
• It is particularly useful when the process of creating an object is
expensive, time-consuming, or complex, and when the system should
avoid creating new objects from scratch.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Analogy
• Mitotic cell division
• After mitotic division, a pair of identical cells is formed.
• The original cell acts as a prototype and takes an active role in
creating the copy.
• Another Example: Rubber Stamp

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components
• Prototype: The Prototype interface declares the cloning methods. In
most cases, it’s a single clone method.
• ConcretePrototype: The Concrete Prototype class implements the
cloning method.
• Client: The Client can produce a copy of any object that follows the
prototype interface.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Cloning Book Objects
• Step 1: Define the Prototype Interface
Example – Cloning Book Objects
• Step 2: Create the Concrete Prototype.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Cloning Book Objects
• Step 3: Demonstrate Prototype Usage

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Prototype Pattern

• You can clone objects without coupling to their concrete classes.

• You can get rid of repeated initialization code in favor of cloning
pre- built prototypes.
• You can produce complex objects more conveniently.
• You get an alternative to inheritance when dealing with
configuration presets for complex objects.
Disadvantages of Prototype Pattern
• Cloning complex objects that have circular references might be very
tricky.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
5. Singleton Pattern
• Singleton is a creational design pattern that lets you ensure that a
class has only one instance, while providing a global access point to
this instance.
• This pattern is commonly used for managing shared resources like
database connections, configurations, or logging services.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Analogy
• The government is an excellent example of the Singleton pattern.
• A country can have only one official government.
• Regardless of the personal identities of the individuals who form
governments, the title, “The Government of X”, is a global point of
access that identifies the group of people in charge.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 1: Create the Singleton
Class
Example
• Step 2: Client Access

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Features of Singleton Pattern
• Private Constructor: Ensures that no other class can instantiate the
Singleton class directly.
• Static Instance: The instance variable holds the single instance of the
class.
• Lazy Initialization: The instance is created only when it is first
requested using the getInstance method.
• Thread Safety: The synchronized keyword ensures thread safety, so
only one thread can initialize the instance at a time.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Singleton Pattern

• You can be sure that a class has only a single instance.

• You gain a global access point to that instance.
• The singleton object is initialized only when it’s requested for the
first
time.
Disadvantages of Singleton Pattern
• Violates the Single Responsibility Principle. The pattern solves two
problems at the time.
• The Singleton pattern can mask bad design, for instance, when the
components of the program know too much about each other.
• The pattern requires special treatment in a multithreaded environment
so that multiple threads won’t create a singleton object several times.
• It may be difficult to unit test the client code of the Singleton because
many test frameworks rely on inheritance when producing mock objects.
Since the constructor of the singleton class is private and overriding static
methods is impossible in most languages, you will need to think of a
creative way to mock the singleton. Or just don’t write the tests. Or don’t
use the Singleton pattern.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
B. Structural Design Patterns
• Structural design patterns explain how to assemble objects and classes
into larger structures, while keeping these structures flexible and efficient.
• It focuses on the organization and composition of classes and objects.
• These patterns are intended to ease the design process by ensuring that
components are properly interconnected and function cohesively.
• Types
• Adapter Pattern
• Bridge Pattern
• Composite Pattern
• Decorator Pattern
• Façade Pattern
• Flyweight Pattern
• Proxy Pattern

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
1. Adapter Pattern
• Adapter is a structural design pattern that allows objects with
incompatible interfaces to collaborate.

Problem

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Solution
• Adapter is a special object that
converts the interface of one
object so that another object
can understand it.
• An adapter wraps one of the
objects to hide the complexity
of conversion happening
behind the scenes.
• The wrapped object isn’t even
aware of the adapter.
Analogy
• When you travel from the US to Europe for the first time, you may get
a surprise when trying to charge your laptop.
• The power plug and sockets standards are different in different
countries.
• That’s why your US plug won’t fit a German socket.
• The problem can be solved by using a power plug adapter that has
the American-style socket and the European-style plug.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components
• Target Interface: The interface that the client expects to use.
• Adaptee: The existing class with a different interface. (Service)
• Adapter: A class that implements the target interface and delegates
calls to the adaptee.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Suppose you have a legacy VGADisplay class that provides output
through VGA.
• However, your application expects all displays to follow the modern
HDMIDisplay interface.
• Here, the adapter pattern can help bridge this gap.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 1: Define the Target Interface

• Step 2: Adaptee Class (Incompatible with Target Interface)

Example
• Step 3: Adapter Class

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 4: Client Code

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Adapter Pattern
• Single Responsibility Principle: You can separate the interface or data
conversion code from the primary business logic of the program.
• Open/Closed Principle: You can introduce new types of adapters into
the program without breaking the existing client code, as long as they
work with the adapters through the client interface.
Disadvantages of Adapter Pattern
• The overall complexity of the code increases because you need to
introduce a set of new interfaces and classes.
• Sometimes it’s simpler just to change the service class so that it
matches the rest of your code.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
2. Bridge Pattern
• Bridge is a structural design pattern that lets you split a large class or
a set of closely related classes into two separate hierarchies—
abstraction and implementation—which can be developed
independently of each other.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components of the Bridge Pattern
• Abstraction: The high-level control layer that defines the abstraction's
interface.
• Refined Abstraction: Extends the Abstraction and provides more
specific behavior.
• Implementor: Defines the interface for the implementation.
• Concrete Implementor: Implements the Implementor interface.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example

• Imagine a Shape abstraction that can be drawn in different colors.

• You could combine shapes and colors using a subclass for every
possible combination (e.g., RedCircle, BlueRectangle), but this
leads to an explosion of subclasses.
• The Bridge Pattern allows you to decouple the Shape abstraction
from the Color implementation.
Example
• Step 1: Implementor - defines the
interface for implementation classes

• Step 2: Concrete Implementors -

provide concrete implementations of
the Color interface

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 3: Abstraction - defines the high-level interface

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 4: Refined Abstraction - concrete implementation of Shape

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 5: Client Access
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Bridge Pattern
• You can create platform-independent classes and apps.
• The client code works with high-level abstractions. It isn’t exposed to
the platform details.
• Open/Closed Principle: You can introduce new abstractions and
implementations independently from each other.
• Single Responsibility Principle: You can focus on high-level logic in
the abstraction and on platform details in the implementation.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages of Bridge Pattern
• You might make the code more complicated by applying the pattern
to a highly cohesive class.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
3. Composite Pattern
• Composite is a structural design pattern that lets you compose
objects into tree structures and then work with these structures as if
they were individual objects.
• Using the Composite pattern makes sense only when the core model
of your app can be represented as a tree.

The Composite pattern suggests that you work

with Products and Boxes through a common
interface which declares a method for calculating
the total price.
Key Components of the Composite Pattern
• Component: The interface or abstract class that defines the common
methods for all elements in the hierarchy.
• Leaf: Represents the end objects of the composition, implementing
the Component interface.
• Composite: Contains child components, which can be both Leaf and
Composite objects. It implements the Component interface and
delegates work to child components.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• File System (Files and Folders)
• Imagine a file system where folders can contain files or other folders, and we
want to treat files and folders uniformly.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 1: Component

• Step 2: Leaf: Represents a file

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Step 3: Composite:
Represents a folder that
can contain files or other
folders
Example
• Step 4: Client

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Composite Pattern
• You can work with complex tree structures more conveniently: use
polymorphism and recursion to your advantage.
• Open/Closed Principle: You can introduce new element types into
the app without breaking the existing code, which now works with
the object tree.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages of Composite Pattern
• It might be difficult to provide a common interface for classes whose
functionality differs too much.
• In certain scenarios, you’d need to overgeneralize the component
interface, making it harder to comprehend.
4. Decorator Pattern/ Wrapper Pattern
• Decorator is a structural design pattern that lets you attach new
behaviors to objects by placing these objects inside special wrapper
objects that contain the behaviors.
• The Decorator Pattern is a structural design pattern that allows you
to dynamically add behavior or responsibilities to objects without
altering their code.
• It provides a flexible alternative to subclassing for extending
functionality.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components of the Decorator Pattern
• Component: The common interface or abstract class for objects that
can have responsibilities added to them.
• Concrete Component: The base implementation of the Component
interface, representing the object to which additional responsibilities
can be attached.
• Decorator: An abstract class that implements the Component
interface and contains a reference to a Component object.
• Concrete Decorators: Extend the Decorator class and add new
behaviors or responsibilities to the Component.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Imagine a coffee shop where you can order a basic coffee and
dynamically add extra options like milk, sugar, or caramel.
• Each addition modifies the behavior of the coffee object without
altering the core coffee class.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
Step 1: Step 2:
Example

Step 3:

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
Step 4:

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example

Step 5:

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Decorator Pattern
• You can extend an object’s behavior without making a new subclass.
• You can add or remove responsibilities from an object at runtime.
• You can combine several behaviors by wrapping an object into
multiple decorators.
• Single Responsibility Principle: You can divide a monolithic class that
implements many possible variants of behavior into several smaller
classes.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages of Decorator Pattern
• It’s hard to remove a specific wrapper from the wrappers stack.
• It’s hard to implement a decorator in such a way that its behavior
doesn’t depend on the order in the decorators stack.
• The initial configuration code of layers might look pretty ugly.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
5. Façade Pattern
• Facade is a structural design pattern that provides a simplified
interface to a library, a framework, or any other complex set of
classes.
• It hides the complexities of the system and provides a client with a
unified interface, making the subsystem easier to use.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components of the Facade Pattern
• Subsystem: Represents the complex set of classes or components
with intricate interdependencies.
• Facade: A single unified class that provides a simplified interface to
the subsystem. It delegates client requests to appropriate subsystem
objects.
• Client: Interacts with the Facade instead of dealing with the
complexity of the subsystem.
Example
• Imagine a home theater system with multiple components like a DVD
player, projector, sound system, and lights.
• The Facade Pattern can simplify the process of turning on the home
theater system with a single method call.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 1

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 2

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 3
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Façade Pattern
• You can isolate your code from the complexity of a subsystem.

Disadvantages of Façade Pattern

• A facade can become a god object coupled to all classes of an app.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
6. Flyweight Pattern
• Flyweight is a structural design pattern that lets you fit more objects
into the available amount of RAM by sharing common parts of state
between multiple objects instead of keeping all of the data in each
object.
• The Flyweight Pattern is a structural design pattern that reduces
memory usage by sharing objects instead of creating new instances.
• It is particularly useful when dealing with a large number of objects
that have a high degree of similarity.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components of Flyweight Pattern
• Intrinsic State: The part of an object’s state that is shared and does
not change for different contexts.
• Extrinsic State: The part of an object’s state that is unique and must
be provided at runtime.
• Flyweight Factory: Ensures that shared objects are reused instead of
creating new ones.
• Client: Uses the Flyweight objects and provides the extrinsic state.
Example
• Imagine a drawing application where users can draw multiple shapes
like circles, rectangles, or triangles.
• Each shape has common properties like color and fill style (intrinsic
state) but unique properties like position and size (extrinsic state).
• Instead of creating new shape objects for each shape, we can use the
Flyweight Pattern to share common properties.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 1 and 2

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 3

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 4
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Flyweight Pattern
• You can save lots of RAM, assuming your program has tons of similar
objects.

Disadvantages of Flyweight Pattern

• You might be trading RAM over CPU cycles when some of the context data
needs to be recalculated each time somebody calls a flyweight method.
• The code becomes much more complicated. New team members will
always be wondering why the state of an entity was separated in such a
way.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
7. Proxy Pattern
• Proxy is a structural design pattern that lets you provide a substitute
or placeholder for another object.
• A proxy controls access to the original object, allowing you to perform
something either before or after the request gets through to the
original object.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components of Proxy Pattern
• Subject
• Real Subject
• Proxy
• Virtual Proxy: Controls access to an object that is resource-heavy and only initializes
it when needed.
• Protection Proxy: Controls access to an object by ensuring that only authorized
clients can access it.
• Remote Proxy: Represents an object that exists on a different machine or server.
• Caching Proxy: Stores the result of expensive operations to improve performance by
avoiding repeated computations.
• Client
Example
• We have a TaskProcessor that processes tasks.
• However, we don't want to process the task directly every time;
instead, we will use a Proxy to log when the task is being processed
and handle the processing in a controlled way.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages of Proxy Pattern
• You can control the service object without clients knowing about it.
• You can manage the lifecycle of the service object when clients don’t
care about it.
• The proxy works even if the service object isn’t ready or is not
available.
• Open/Closed Principle: You can introduce new proxies without
changing the service or clients.
Disadvantages of Proxy Pattern
• The code may become more complicated since you need to introduce
a lot of new classes.
• The response from the service might get delayed.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
C. Behavioural Design Pattern
• Behavioral design patterns focus on the interaction and responsibility of objects.
• These patterns help in defining how objects communicate and collaborate with each other,
promoting flexibility and scalability in complex systems.
• Behavioral patterns emphasize the dynamic relationships between objects rather than their static
structures.
• Types
• Chain of Responsibility
• Command
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Characteristics
• Encapsulation of Behavior: They allow encapsulating processes and
algorithms to promote reusability.
• Object Interaction: Define clear ways objects interact and delegate
responsibilities.
• Loose Coupling: Reduce dependencies among interacting objects,
making systems more maintainable and extensible.
• Dynamic Behavior: Enable runtime changes in behavior without
altering the object's core logic.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
1. Chain of Responsibility
• Chain of Responsibility is a behavioral design pattern that lets you
pass requests along a chain of handlers.
• Upon receiving a request, each handler decides either to process the
request or to pass it to the next handler in the chain.
Key Components
• Handler (Abstract Class or Interface): Defines a method to handle
requests and a reference to the next handler in the chain.
• Concrete Handlers: Implement the handler interface and decide
whether to process the request or pass it to the next handler.
• Client: Sends requests to the first handler in the chain.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• A Helpdesk System
• Let's consider a helpdesk system where user issues are categorized into three
levels:
• Level 1: General Queries
• Level 2: Technical Issues
• Level 3: Critical Issues

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 1

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 2
Example – Step 3

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages
• You can control the order of request handling.
• Single Responsibility Principle. You can decouple classes that invoke
operations from classes that perform operations.
• Open/Closed Principle. You can introduce new handlers into the app
without breaking the existing client code.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages
• Some requests may end up unhandled.
2. Command Pattern
• The Command Pattern is a behavioral design pattern that
encapsulates a request as an object, thereby allowing you to:
• Parameterize objects with different requests.
• Queue requests.
• Log or store the history of executed commands for undo/redo functionality.
• It decouples the object that invokes the operation from the one that
performs it, promoting flexibility and extensibility in software design.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components
• Command Interface: Declares the execute() method to encapsulate
the action to be performed.
• Concrete Commands: Implement the Command interface to define
the binding between the receiver and an action.
• Receiver: The actual object that performs the action when the
command is executed.
• Invoker: The object that triggers the command’s execution.
• Client: Configures the concrete commands and links them to the
invoker.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• A Home Automation System
• Let’s consider a scenario where we have a home automation system
that can control devices like lights and fans. The system will allow us
to turn devices ON or OFF using commands.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 1 and 2
Example – Step 3

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 4

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 5

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages
• Single Responsibility Principle. You can decouple classes that invoke
operations from classes that perform these operations.
• Open/Closed Principle. You can introduce new commands into the
app without breaking existing client code.
• You can implement undo/redo.
• You can implement deferred execution of operations.
• You can assemble a set of simple commands into a complex one.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages
• The code may become more complicated since you’re introducing a
whole new layer between senders and receivers.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
3. Iterator Pattern
• The Iterator Pattern is a behavioral design
pattern that provides a way to access
elements of a collection sequentially
without exposing its underlying
implementation.
• This pattern decouples the iteration process
from the collection, making the code more
flexible and reusable.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components
• Iterator Interface: Defines methods for accessing and traversing
elements in a collection (e.g., hasNext() and next()).
• Concrete Iterator: Implements the iterator interface to provide
traversal functionality.
• Collection Interface: Defines methods to create an iterator object
(e.g., createIterator()).
• Concrete Collection: Implements the collection interface and
provides an implementation for creating an iterator.
Example
• A Custom Collection of Names
• Let’s create a custom collection of names and use the Iterator pattern
to traverse the collection.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 1,2,3

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – 4,5

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages
• Single Responsibility Principle. You can clean up the client code and
the collections by extracting bulky traversal algorithms into separate
classes.
• Open/Closed Principle. You can implement new types of collections
and iterators and pass them to existing code without breaking
anything.
• You can iterate over the same collection in parallel because each
iterator object contains its own iteration state.
• For the same reason, you can delay an iteration and continue it when
needed.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages
• Applying the pattern can be an overkill if your app only works with
simple collections.
• Using an iterator may be less efficient than going through elements
of some specialized collections directly.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
4. Mediator Pattern
• The Mediator Pattern is a behavioral design pattern that defines an
object (the mediator) that encapsulates how a set of objects interact.
• Instead of having objects refer to each other directly, they
communicate through the mediator, promoting loose coupling.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components
1. Mediator Interface: Defines methods for communication between
objects.
2. Concrete Mediator: Implements the mediator interface and manages
communication between colleague objects.
3. Colleague Interface: Represents components that communicate via
the mediator.
4. Concrete Colleagues: Implement the colleague interface and use the
mediator for communication.
Example
• Chat Room
• Let’s implement a simple chat room where users (colleagues)
communicate through a central chat room (mediator).

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 1,2

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 3,4

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 5
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages
• Single Responsibility Principle. You can extract the communications
between various components into a single place, making it easier to
comprehend and maintain.
• Open/Closed Principle. You can introduce new mediators without
having to change the actual components.
• You can reduce coupling between various components of a program.
• You can reuse individual components more easily.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages
• Over time a mediator can evolve into a God Object.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
5. Memento Pattern
• The Memento Pattern is a behavioral design pattern that allows an
object to save and restore its state without violating encapsulation.
• It achieves this by externalizing the state of an object into a memento
object, which can be stored and restored as needed.
Key Components
• Originator: The object whose state is to be saved and restored.
• Memento: The object that stores the originator’s state.
• Caretaker: The object that manages and restores the mementos.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Text Editor with Undo Functionality
• Imagine a text editor where the user can type text and undo their last
action. The Memento Pattern is a great choice to implement this
functionality.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 1,2

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 3
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Alternative Implementation

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Alternative Implementation

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages
• You can produce snapshots of the object’s state without violating its
encapsulation.
• You can simplify the originator’s code by letting the caretaker
maintain the history of the originator’s state.
Disadvantage
• The app might consume lots of RAM if clients create mementos too
often.
• Caretakers should track the originator’s lifecycle to be able to destroy
obsolete mementos.
• Most dynamic programming languages, such as PHP, Python and
JavaScript, can’t guarantee that the state within the memento stays
untouched.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
6. Observer Pattern
• The Observer Pattern is a behavioral design pattern used to define a
one-to-many dependency between objects.
• When the state of one object (called the Subject) changes, all its
dependents (called Observers) are notified and updated
automatically.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components
• Subject / Publisher: Maintains a list of observers and provides
methods to add, remove, and notify them of changes.
• Observer / Subscriber: Defines an interface or an abstract class to be
implemented by concrete observer classes. Observers receive
updates from the subject.
• ConcreteSubject/ ConcreatePublisher: A specific implementation of
the Subject, where the actual state resides and changes trigger
notifications to observers.
• ConcreteObserver/ ConcreteSubscriber: Implements the Observer
interface and reacts to changes in the Subject's state.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Weather monitoring system where the WeatherStation (Subject)
notifies its observers (MobileDevice, WebApp) about temperature
updates.
Example – Step 1,2

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 3

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 4

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 5
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages
• Open/Closed Principle. You can introduce new subscriber classes
without having to change the publisher’s code (and vice versa if
there’s a publisher interface).
• You can establish relations between objects at runtime.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages
• Subscribers are notified in random order.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
7. State Pattern
• The State Pattern is a behavioral design pattern that allows an object
to change its behavior when its internal state changes.
• This pattern is particularly useful when an object has multiple states
and the behavior associated with these states is complex or requires
frequent changes.
Key Components
• Context: The object whose behavior changes with its state.Maintains
a reference to the current state and delegates state-specific behavior
to it.
• State Interface: Defines a common interface for all the concrete
states.Each concrete state implements this interface and defines its
behavior.
• Concrete States: Implement specific behavior associated with a state
of the context.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Traffic Light System
• A traffic light has three states: Red, Yellow, and Green.
• Each state has a specific behavior, and the light transitions to the next state
after performing its task.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 1,2

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 4
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages
• Single Responsibility Principle. Organize the code related to particular
states into separate classes.
• Open/Closed Principle. Introduce new states without changing
existing state classes or the context.
• Simplify the code of the context by eliminating bulky state machine
conditionals.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantage
• Applying the pattern can be overkill if a state machine has only a few
states or rarely changes.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
8. Strategy Pattern
• The Strategy Pattern is a behavioral design pattern that enables
selecting an algorithm's behavior at runtime.
• It defines a family of algorithms, encapsulates each one, and makes
them interchangeable without modifying the client code.
• This pattern promotes the Open-Closed Principle, allowing you to
introduce new strategies without changing the existing code.
Key Components
• Strategy Interface: Defines a common interface for all supported
algorithms.
• Concrete Strategies: Implement the interface, each with a specific
behavior.
• Context: Maintains a reference to a strategy object and allows
switching between strategies.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• We want to provide different sorting algorithms (e.g., Bubble Sort,
Quick Sort) that a client can choose at runtime.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example –Step 1,2

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 3,4
Context
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages
• You can swap algorithms used inside an object at runtime.
• You can isolate the implementation details of an algorithm from the
code that uses it.
• You can replace inheritance with composition.
• Open/Closed Principle. You can introduce new strategies without
having to change the context.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages
• If you only have a couple of algorithms and they rarely change, there’s
no real reason to overcomplicate the program with new classes and
interfaces that come along with the pattern.
• Clients must be aware of the differences between strategies to be
able to select a proper one.
• A lot of modern programming languages have functional type
support that lets you implement different versions of an algorithm
inside a set of anonymous functions. Then you could use these
functions exactly as you’d have used the strategy objects, but without
bloating your code with extra classes and interfaces.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
9. Template Method Pattern
• Template Method is a behavioral design pattern that defines the
skeleton of an algorithm in the superclass but lets subclasses
override specific steps of the algorithm without changing its
structure.
Structure

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
• Beverage Preparation
• We want to prepare tea and coffee using a common framework but
with variations in preparation steps.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Abstract Class
Concrete Class

Dr.Sw eth a.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Client Access
Advantages
• You can let clients override only certain parts of a large algorithm,
making them less affected by changes that happen to other parts of
the algorithm.
• You can pull the duplicate code into a superclass.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages
• Some clients may be limited by the provided skeleton of an algorithm.
• You might violate the Liskov Substitution Principle by suppressing a
default step implementation via a subclass.
• Template methods tend to be harder to maintain the more steps they
have.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
10. Visitor Pattern
• The Visitor Pattern is a behavioral design pattern that lets you
separate algorithms (operations) from the objects on which they
operate.
• This pattern allows adding new operations to existing object
structures without modifying their classes.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components
• Visitor: Declares operations for all types of elements in the object
structure.
• Concrete Visitor: Implements the operations defined in the visitor.
• Element: Declares an accept method to allow visitors to perform
operations.
• Concrete Element: Implements the accept method, allowing a visitor
to "visit" it.
• Object Structure: Holds the collection of elements to be visited.
Example
• File System with Different Types of Files
• We want to perform operations (like size calculation or virus
scanning) on different file types (e.g., text files, image files) without
modifying their classes.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 1,2
Concrete Visitor

Visitor Interface

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example –Step 3,4,5 Object Structure
Concrete Element

Element Interface

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example – Step 6

Client Access
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Advantages
• Open/Closed Principle. You can introduce a new behavior that can
work with objects of different classes without changing these classes.
• Single Responsibility Principle. You can move multiple versions of the
same behavior into the same class.
• A visitor object can accumulate some useful information while
working with various objects. This might be handy when you want to
traverse some complex object structure, such as an object tree, and
apply the visitor to each object of this structure.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Disadvantages
• You need to update all visitors each time a class gets added to or
removed from the element hierarchy.
• Visitors might lack the necessary access to the private fields and
methods of the elements that they’re supposed to work with.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Core Java EE Patterns
• Core Java EE patterns provide standard solutions to recurring problems
encountered while developing enterprise applications.
• These patterns are categorized based on the three primary tiers of an
enterprise application:
• Presentation Tier
• These patterns manage the user interface and interaction with the client, handling requests
and responses effectiv ely.
• Business Tier
• These patterns handle the core business logic, ensuring separation of concerns and efficient
communicat ion.
• Integration Tier
• These patterns manage data access and communication between the applicat ion and external
systems.
1. Presentation Tier

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
1.1 Intercepting Filter
• Description:
• Allows pre-processing and post-
processing of requests and
responses.
• Use Case:
• Authentication, logging, input
validation, or request
transformation.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
1.2 Front Controller
• Description:
• Provides a centralized entry point to handle all client requests.
• Use Case:
• Centralized request processing in web applications.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
1.3 View Helper
• Description:
• Encapsulates logic used in the presentation layer, separating it from business
logic.
• Use Case:
• Formatting or preparing data for display.
1.4 Composite View
• Description:
• Constructs a view from multiple reusable subviews.
• Use Case:
• Websites with reusable headers, footers, and sidebars.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
1.5 Service to Worker
• Description:
• Combines Front Controller and View Helper patterns to handle request
processing and view rendering.
• Use Case:
• Coordinating business logic and view rendering in web applications.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
2. Business Tier Patterns

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
2.1 Business Delegate
• Description:
• Acts as an intermediary between the
presentation layer and business logic.
• Use Case:
• Reduces coupling between the
presentation and business tiers.
2.2 Session Facade
• Description:
• Provides a unified interface to
encapsulate complex interactions
between business components.
• Use Case:
• Simplifies access to a group of
related services.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
2.3 Application Service
• Description:
• Encapsulates business logic in stateless service objects for reuse.
• Use Case:
• Centralized business rule processing.
2.4 Business Object
• Description:
• Represents data and logic specific to a business domain.
• Use Case:
• Modeling entities like Customer or Order.
2.5 Composite Entity
• Description:
• Aggregates related business objects into a single unit.
• Use Case:
• Handling entities like Invoice with associated LineItems.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
2.6 Transfer Object (DTO)
• Description:
• Reduces remote calls by bundling multiple data attributes into a single object.
• Use Case:
• Transporting data between tiers.

2.7 Value Object

• Description:
• Immutable, lightweight object for transferring data.
• Use Case:
• Use for read-only configurations or preferences.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
3. Integration Tier Patterns
3.1 Data Access Object (DAO)
• Description:
• Abstracts persistence logic and provides a consistent API for data access.
• Use Case:
• Performing CRUD operations.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
3.2 Service Locator
• Description:
• Provides a single point of access to locate services such as JNDI or EJBs.
• Use Case:
• Simplifies resource lookup.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
3.3 Message Façade
• Description:
• Encapsulates messaging system interactions like JMS.
• Use Case:
• Simplifies communication with message queues.
3.4 Connector
• Description:
• Provides standardized access to enterprise information systems using JCA.
• Use Case:
• Integration with legacy systems or third-party APIs.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Benefits of Core Java EE Patterns
• Reusability: Promotes reuse of proven solutions across applications.
• Scalability: Helps build applications that can handle increasing loads.
• Maintainability: Ensures separation of concerns and modularity.
• Flexibility: Adapts easily to changes in requirements or technology.
Modern Java EE Pattern
• Modern Java EE (Jakarta EE) patterns refer to best practices, design strategies, and
coding approaches used to build scalable, maintainable, and efficient enterprise
applications using the Jakarta EE platform (formerly Java EE).
• These patterns address common challenges in enterprise application development, such
as handling large-scale data, ensuring loose coupling, and managing distributed
systems.
• Types
• Architectural Patterns
• Behavioural and Integration Patterns
• Data and Persist ence Patterns
• Securit y Patterns
• Resi lience and Scalabi lity Patterns
• Design Patterns
• Testing and Deploy ment Patterns
• User Interface Patterns

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
1. Architectural Patterns
• Boundary-Control-Entity (BCE) Pattern
• Divides an application into:
• Boundary: Handles external interaction (e.g., REST endpoints).
• Control: Encapsulates business logic.
• Entity: Represents persistent data.
• Microservices Pattern
• Breaks down applications into smaller, independently deployable services.
• Uses REST or messaging for inter-service communication.
• Promotes scalability and maintainability.
• Hexagonal Architecture (Ports and Adapters)
• Separates business logic from external systems like databases or APIs.
• Uses "ports" for input/output abstractions and "adapters" for implementation.
• Service-Oriented Architecture (SOA)
• Encourages reusability by exposing business logic as services.
• Often implemented using SOAP or REST.
• Event-Driven Architecture
• Reacts to events (e.g., user actions or system changes).
• Leverages patterns like Observer, CQRS, or Event Sourcing.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
2. Behavioural and Integration Patterns
• Dependency Injection (DI) Pattern
• Achieves loose coupling by injecting dependencies through CDI (Contexts and Dependency Injection).
• Singleton Service Pattern
• Ensures a single instance of a service is shared across the application.
• Observer Pattern
• Enables decoupled components to respond to events using CDI’s @Observes.
• Producer/Consumer Pattern
• Used in messaging systems (e.g., JMS or Kafka) to decouple message production and consumption.
• Asynchronous Processing Pattern
• Handles long-running tasks using @Asynchronous methods or messaging queues.
• Retry Pattern
• Automatically retries operations (e.g., remote calls) upon failure, often combined with exponential backoff.
• Circuit Breaker Pattern
• Prevents cascading failures in distributed systems by temporarily halting requests to failing services.
• Bulkhead Pattern
• Isolates parts of the system to limit the impact of failures in one module on others.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
3. Data and Persistence Patterns
• Repository Pattern
• Encapsulates database access logic, separating it from the business logic.
• Unit of Work Pattern
• Ensures atomic operations by grouping multiple changes into a single transaction.
• DTO (Data Transfer Object) Pattern
• Transfers data between layers, often for optimizing REST responses or remote calls.
• Active Record Pattern
• Combines data persistence and business logic within a single entity (less common in
Java EE).
• Query Object Pattern
• Encapsulates database queries, often using JPQL or Criteria API.
4. Security Patterns
• Role-Based Access Control (RBAC)
• Manages permissions based on user roles using annotations like
@RolesAllowed.
• Security Context Pattern
• Propagates authentication and authorization details throughout the
application.
• Token-Based Authentication Pattern
• Utilizes tokens (e.g., JWT) for stateless authentication in microservices.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
5. Resilience and Scalability Patterns
• Load Balancing Pattern
• Distributes incoming requests across multiple servers or instances.
• Cache Pattern
• Improves performance by storing frequently accessed data in memory (e.g.,
using JCache).
• Failover Pattern
• Ensures high availability by automatically switching to a backup service during
failures.
• Sharding Pattern
• Distributes data across multiple databases to improve scalability.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
6. Design Patterns
• Builder Pattern
• Constructs complex objects in a readable, step-by-step manner.
• Factory Pattern
• Creates instances of classes without exposing their instantiation logic.
• Adapter Pattern
• Provides a bridge between incompatible interfaces or systems.
• Proxy Pattern
• Adds an intermediary to control access to a resource.
• Decorator Pattern
• Dynamically adds responsibilities to objects (e.g., request/response interceptors).

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
7. Testing and Deployment Patterns
• Test Pyramid Pattern
• Encourages a mix of unit, integration, and UI tests for balanced test coverage.
• Canary Deployment Pattern
• Gradually rolls out new versions to a subset of users to minimize risks.
• Blue-Green Deployment Pattern
• Switches traffic between two environments (blue and green) to ensure zero-
downtime deployments.
• Sidecar Pattern
• Attaches auxiliary components (e.g., monitoring, logging) as sidecars in a
containerized environment.
8. User Interface Patterns
• Model-View-Controller (MVC) Pattern
• Separates concerns between data (Model), presentation (View), and control
logic (Controller).
• Presentation Model Pattern
• Creates a view-independent model to handle UI logic (used with JSF or similar
frameworks).

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Java EE Blueprint Patterns
• Java EE (now Jakarta EE) Blueprints are a collection of architectural
patterns, design strategies, and best practices to guide developers in
building enterprise applications.
• Below is a list of various Java EE Blueprint patterns categorized by
functionality:
• Presentation Tier Patterns
• Business Tier Patterns
• Integration Tier Patterns
• Messaging Patterns
• Security Patterns
• Concurrency and Transaction Patterns
• Cross-Cutting Patterns
• Deployment Patterns

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
1. Presentation Tier Patterns
• These patterns deal with the user interface and its interaction with
the application.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
2. Business Tier Patterns
• These patterns manage business logic and coordinate between the
presentation and integration tiers.
3. Integration Tier Patterns
• These patterns focus on interacting with external systems, including
databases, messaging, and external APIs.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
4. Messaging Patterns
• These patterns deal with asynchronous communication and
integration via messaging systems.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
5. Security Patterns
• These patterns address authentication, authorization, and data
protection.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
6. Concurrency and Transaction Patterns
• These patterns help manage concurrent tasks and ensure data
consistency.
7. Cross-Cutting Patterns
• These patterns address concerns that span multiple layers of an
application.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
8. Deployment Patterns
• These patterns focus on application deployment and scaling
strategies.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.