PATTERN

Introduction
What is pattern

How to create it.

Types of patterns.

Pattern matching explain examples

Method of thepatterns.

Laudagues of pattern.

Examples related types of patterns.

 PATTERN

• A design pattern provides a general reusable solution

for the common problems occurs in software design.
• The patterns typically show relationships and
interactions between classes or objects.
• The idea is to speed up the development process by
providing well tested, proven development/design
paradigm.
• Design patterns are programming language
independent strategies for solving a common
problem.
• That means a design pattern represents an idea,
not a particular implementation.
• By using the design patterns you can make your code
more flexible, reusable and maintainable.

• It’s not mandatory to implement design patterns in your

project always.
• Design patterns are not meant for project development.
Design patterns are meant for common problem-solving.
Whenever there is a need, you have to implement a
suitable pattern to avoid such problems in the future.
• To find out which pattern to use. You just have to try to
understand the design patterns and it’s purposes. Only by
then you will be able to pick the right one.
Types of Design Patterns
1. Creational
These design patterns are all about class instantiation or
object creation. These patterns can be further categorized
into Class- creational patterns and object-creational
patterns. While class- creation patterns use inheritance
effectively in the instantiation process, object-creation
patterns use delegation effectively to get the job done.

Suppose a developer wants to create a simple DBConnection

class to connect to a database and wants to access the
database at multiple locations from code, generally what
developer will do is create an instance of DBConnection
class and use it for doing database operations wherever
required. Which results in creating multiple connections from
the database as each instance of DBConnection class will
have a separate connection to the database. In order to deal
with it, we create DBConnection class as a singleton class,
so that only one instance of DBConnection is created and a
single connection is established. Because we can manage
DB Connection via one instance so we can control load
balance, unnecessary connections, etc.
2. Structural
These design patterns are about organizing different
classes and objects to form larger structures and provide
new functionality. Structural design patterns are Adapter,
Bridge, Composite, Decorator, Facade, Flyweight, Private
Class Data, and Proxy.

When 2 interfaces are not compatible with each other and

want to make establish a relationship between them through
an adapter its called adapter design pattern. Adapter pattern
converts the interface of a class into another interface or
classes the client expects that is adapter lets classes works
together that could not otherwise because of incompatibility.
so in these type of incompatible scenarios, we can go for the
adapter pattern.
3. Behavioral
Behavioral patterns are about identifying common
communication patterns between objects and realize
these patterns.
Behavioral patterns are Chain of responsibility, Command,
Interpreter, Iterator, Mediator, Memento, Null Object,
Observer, State, Strategy, Template method, Visitor

Template pattern defines the skeleton of an algorithm in an

operation deferring some steps to sub-classes, Template
method lets subclasses redefine certain steps of an algorithm
without changing the algorithm structure. say for an example
in your project you want the behavior of the module can be
extended, such that we can make the module behave in new
and different ways as the requirements of the application
change, or to meet the needs of new applications. However,
No one is allowed to make source code changes to it. it
means you can add but can’t modify the structure in those
scenarios a developer can approach template design pattern.
 Design Seminar | 2

EVOLUTION OF STRUCTURAL LANGUAGE THROUGH HISTORY

MEANS OF ACHIEVING STRUCTURAL LANGUAGE- PATTERNS

a. What ispattern?
An architectural pattern is a concept that solves and delineates some essential cohesive
elements of a software architecture. Countless different architecture may implement the
same pattern and share the related characteristics. Patterns are often defined as "strictly
described and commonlyavailable.
An architectural pattern is a general, reusable solution to a commonly occurring problem in
software architecture within a given context. The architectural patterns address various
issues in software engineering, such as computer hardware performance limitations, high
availability and minimization of a business risk. Some architectural patterns have been
implemented within software frameworks.
b. How to create it?
Several different formats are used in the literature for describing patterns, and no single
format has achieved widespread acceptance. However, there is broad agreement on the
types of things that a pattern should contain.
The headings which follow are taken from Pattern-Oriented Software Architecture: A System
of Patterns. The elements described below will be found in most patterns, even if different
headings are used to describe them.
The preconditions under which the pattern is applicable - a description of the initial state
before the pattern are applied.
A description, using text and/or graphics, of how to achieve the intended goals and
objectives. The description should identify both the solution's static structure and its dynamic
behavior - the people and computing actors, and their collaborations. The description may
include guidelines for implementing the solution. Variants or specializations of the solution
may also be described.
Although design patterns have been the focus of widespread interest in the software industry
for several years, particularly in the object-oriented and component-based software fields, it
is only recently that there has been increasing interest in architecture patterns - extending
the principles and concepts of design patterns to the architecture domain.
The technical literature relating to this field is complicated by the fact that many people in
the software field use the term "architecture" to refer to software, and many patterns
described as "architecture patterns" are high-level software design patterns. This simply
makes it all the more important to be precise in use of terminology.
 Design Seminar | 3

Source- Tutorialspoint

c. Types of pattern
1.Adapter
2.Bridge
3.Composite
4.Decorator
5.Façade
6.Flyweight
7.Proxy
d. Method of the patterns
1. Adapter: It is a structural design pattern that allows objects with incompatible interfaces to
collaborate.
 Design Seminar | 4

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. For example, you
can wrap an object that operates in meters and kilometers with an adapter that converts all
of the data to imperial units such as feet and miles.
The adapter gets an interface, compatible with one of the existing objects.
Using this interface, the existing object can safely call the adapter’s methods.

Upon receiving a call, the adapter passes the request to the second object, but in a format
and order that the second object expects.

2. Bridge
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.
 Design Seminar | 5

The abstraction object controls the appearance of the app, delegating the actual work to
the linked implementation object.
3. Composite
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.

Armies of most countries are structured as hierarchies. An army consists of several divisions; a
division is a set of brigades, and a brigade consists of platoons, which can be broken down
into squads. Finally, a squad is a small group of real soldiers. Orders are given at the top of
the hierarchy and passed down onto each level until every soldier knows what needs to be
done.
4. Decorator
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.

Wearing clothes is an example of using decorators. When you’re cold, you wrap yourself in a
sweater. If you’re still cold with a sweater, you can wear a jacket on top. If it’s raining, you
can put on a raincoat. All of these garments “extend” your basic behavior but aren’t part of
you, and you can easily take off any piece of clothing whenever you don’t need it.
The client code would need to wrap a basic notifier object into a set of decorators that
match the client’s preferences. The resulting objects will be structured as a stack.

When does a simple wrapper become the real decorator? As I mentioned, the wrapper
implements the same interface as the wrapped object. That’s why from the client’s
perspective these objects are identical.
 Design Seminar | 6

Make the wrapper’s reference field accept any object that follows that interface. This will let
you cover an object in multiple wrappers, adding the combined behavior of all the
wrappers to it.

5. Façade
Facade is a structural design pattern that provides a simplified interface to a library, a
framework, or any other complex set of classes.

A facade is a class that provides a simple interface to a complex subsystem which contains
lots of moving parts. A facade might provide limited functionality in comparison to working
with the subsystem directly. However, it includes only those features that clients really care
about.
 Design Seminar | 7

6. Flyweight
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.
This constant data of an object is usually called the intrinsic state. It lives within the object;
other objects can only read it, not change it. The rest of the object’s state, often altered
“from the outside” by other objects, is called the extrinsic state.
The Flyweight pattern suggests that you stop storing the extrinsic state inside the object.
Instead, you should pass this state to specific methods which rely on it. Only the intrinsic state
stays within the object, letting you reuse it in different contexts. As a result, you’d need fewer
of these objects since they only differ in the intrinsic state, which has much fewer variations
than the extrinsic.
Since the same flyweight object can be used in different contexts, you have to make sure
that its state can’t be modified. A flyweight should initialize its state just once, via constructor
parameters. It shouldn’t expose any setters or public fields to other objects.
For more convenient access to various flyweights, you can create a factory method that
manages a pool of existing flyweight objects. The method accepts the intrinsic state of the
desired flyweight from a client, looks for an existing flyweight object matching this state, and
returns it if it was found. If not, it creates a new flyweight and adds it to the pool.
There are several options where this method could be placed. The most obvious place is a
flyweight container. Alternatively, you could create a new factory class. Or you could make
the factory method static and put it inside an actual flyweight class.
 Design Seminar | 8

7. Proxy
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.
The Proxy pattern suggests that you create a new proxy class with the same interface as an
original service object. Then you update your app so that it passes the proxy object to all of
the original object’s clients. Upon receiving a request from a client, the proxy creates a real
service object and delegates all the work to it.

credit card is a proxy for a bank account, which is a proxy for a bundle of cash. Both
implement the same interface: they can be used for making a payment. A consumer feels
great because there’s no need to carry loads of cash around. A shop owner is also happy
since the income from a transaction gets added electronically to the shop’s bank account
without the risk of losing the deposit or getting robbed on the way to the bank.
 Design Seminar | 1

EVOLUTION OF STRUCTURAL LANGUAGE THROUGH HISTORY

MEANS OF ACHIEVING STRUCTURAL LANGUAGE- PATTERNS

• Seek out pattern sources. For systems you are the steward of, seek out sources of
architectural patterns. Examples include Net-centric Enterprise Solutions for
Interoperability (NESI), and the Electronic Systems Center Strategic Technical Plan
These two are particularly applicable to problems of enterprise-level net-centricity.
• Be a pattern steward. Recognize and capture patterns for reuse by others. Base
patterns on proven experience in a common form or expression that is amenable to
capture as a corporate knowledge asset. This is one way to help our customers solve
their hard problems.
• Lead the way in pattern usage. Enable and stimulate the selection of technical
solutions based on successful patterns by using them in key documents such as
Technical Requirements Documents, Software Development Plans, Systems
Engineering Management Plans, and other key architecture documents.
• Patterns, patterns, everywhere! Adopt patterns not only in technology-based SE work
but also organizationally and in the process arenas. Works such as the Mission Level
Modeling done by Prem Jain contain workflow patterns that can be reused in
architecture modeling efforts.
 Design Seminar | 2

Architectural Styles vs. Architectural Patterns vs. Design Patterns:

Architectural Styles
• Architectural styles tell us, in very broad strokes, how to organise our code. It’s the
highest level of granularity and it specifies layers, high-level modules of the application
and how those modules and layers interact with each other, the relations between
them. Examples of Architectural Styles:
Component-based
Monolithic application
Layered
Pipes and filters
Event-driven
Publish-subsc ribe
Plug-ins
Client-server
Service-oriented
• An Architectural Style can be implemented in various ways, with a specific technical
environment, specific policies, frameworks or practices.
Architectural Patterns
• A pattern is a recurring solution to a recurring problem. In the case of Architectural
Patterns, they solve the problems related to the Architectural Style. For example,
“what classes will we have and how will they interact, in order to implement a system
with a specific set of layers“, or “what high-level modules will have in our Service-
Oriented Architecture and how will they communicate“, or “how many tiers will our
Client-server Architecture have“.
• Architectural Patterns have an extensive impact on the code base, most often
impacting the whole application either horizontally (ie. how to structure the code
inside a layer) or vertically (ie. how a request is processed from the outer layers into the
inner layers and back). Examples of Architectural Patterns:
Three-tier
Mic rokernel
Model-View-Controller
Model-View-ViewModel
Design Patterns
• Design Patterns differ from Architectural Patterns in their scope, they are more
localised, they have less impact on the code base, they impact a specific section of
the code base, for example:
How to instantiate an object when we only know what type needs to be instantiated
at run time (maybe a Factory Class?);
How to make an object behave differently according to its state (maybe a state
machine, or a Strategy Pattern?).
 Design Seminar | 3

Conclusion

• An Architectural Style is the application design at the highest level of abstraction;

• An Architectural Pattern is a way to implement an Architectural Style;
• A Design Pattern is a way to solve a localised problem.
 Design Seminar | 1

EVOLUTION OF STRUCTURAL LANGUAGE THROUGH HISTORY

MEANS OF ACHIEVING STRUCTURAL LANGUAGE- PATTERNS

• The MVC architectural pattern requires the isolation of business logic (the Model) from
the user interface (the View), with the Controller receiving user input and coordinating
the other two. MVC separation supports the modularization of an application's
functionality and offers a number of benefits.

1.Segregation of Model and View components makes it possible to implement several user

interfaces that reuse the common business logic core.

2.Duplication of low-level Model code is eliminated across multiple UI implementations.

3.Decoupling of Model and View code results in an improved ability to write unit tests for the
core business logic code.

4.Modularity of components allows core logic developers and GUI developers to work
simultaneously without affecting theother.

• The MVC model was first described in 1987 by Steve Burbeck and Trygve Reenskaug at
Xerox PARC and remains a popular architectural pattern in applications and toolkits
today.
• For example, modern UI toolkits such as Nokia's Qt, Apple's Cocoa, Java Swing, and
Microsoft's Foundation Class library were all inspired by MVC
• Taking the example of a single checkbox button, the current on/off state of the button
is stored in the Model, the View draws the current state of the button on the screen,
and the Controller updates the Model state and View display when the user clicks on
the button.
• The implication of MVC separation on code dependency means that View code can
call Model code (to discover the latest state and update the UI), but the opposite is
not true: Model code should have no compile-time knowledge of View code
(because it ties the Model to a single View).
 Design Seminar | 2

• In a simple application, the Controller can effect changes to the Model based on user
input and also communicate those changes to the View so that the UI can be
updated. However, in real-world applications 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 states.
• This requires Model code to inform the View layer when state changes happen.
However, as already stated, the Model code cannot statically bind and call the View
code. This is where observers come in.
• The Observer pattern is a specific instance of the Publish/Subscribe, or pub/sub,
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.
• The observer pattern is therefore an important technique in terms of API design
because it can help you reduce coupling and increase code reuse.
• The Broker pattern is used to structure a complex system as a set of decoupled
interoperating components. This results in better flexibility,maintainability,
changeability and reusability. The Broker pattern includes another pattern that is
called the Proxypattern.
• The role of a proxy is to decouple clients from their servers. The ground station plays the
role of a client in the Broker pattern.
• It sends ground commands to the space craft service system that has the role of the
broker in the pattern. Each ground command is given a time stamp, which specifies
when it is to be sent to the SIXA Measurement Controller.
• When the time is reached to execute a command, the service system will give the
command to the Satellite Computer BIUS,
• which plays the role of Server Proxy in the pattern. The SIXA Measurement Controller
software is decomposed into two independent and almost identical subsystems,
called Energy Measurement Controller and SEC Measurement Controller. These play
the role of servers in the Broker pattern.
 Design Seminar | 3

• MT is an architectural pattern for SaaS applications that permits several customers

(tenants) to share the same instance of the software.
• A tenant is an organizational unit that pays for the use of the SaaS application on a
regular basis (according to the subscription contract). One tenant might consist of
many end-users, therefore MT applications might also be multi-users; we will call
tenancy the set of users of one tenant that run the same customized version of the
application instance.
• The number of instances running in a multitenant environment might be more than
one, resulting in a MT farm. This situation could occur not only because of performance
issues (some tenants might get greedy on computer resources), but also because of
country legislations stating the obligation to store data within country border.