This document discusses software design patterns. It begins by defining what a design pattern is, namely a description of communicating objects and classes that solve common programming problems. The document then outlines the key elements of a design pattern, including its name, problem, solution, and consequences. It categorizes patterns into creational, structural, and behavioral types. Specific patterns like decorator, singleton, and strategy are described in more detail. The benefits of patterns like improved reuse and communication are presented, as well as potential drawbacks such as lack of direct code reuse.

1. SOFTWARE DESIGN
PATTERNS
By:-
NANCY GOEL
USN-1MS09IS059
M.S.RAMIAH INSTITUTE OF TECHNOLOGY
INFORMATION SCIENCE AND ENGINEERING
1

2. INTRODUCTION
 A design pattern is a descriptions of
communicating objects and classes that are
customized to solve a general design problem in a
particular context.
“Each pattern describes a problem which occurs
over and over again in our environment and then
describes the core of the solution to that
problem, in such a way that you can use this
solution a million times over, without ever doing it
in the same way twice”
2

3. CONTD…
 A pattern is a recurring solution to a standard
problem.
 Patterns capture the static and dynamic structure
and collaboration among key participants in software
designs
 A pattern is made by four elements:
• name
• problem
• solution
• consequences
3

4. NAME OF DESIGN PATTERN
 Describe a design problems and its solutions in a
word or two.
 Used to talk about design pattern with our
colleagues.
 Used in the documentation.
 Increase our design vocabulary.
 Have to be coherent and evocative.4

5. PROBLEM
 Describes when to apply the patterns.
 Explains the problem and its context.
 Sometimes include a list of conditions that
must be met before it makes sense to apply the
pattern.
 Have to occur over and over again in our
environment.
5

6. SOLUTION
 Describes the elements that make up the
design, their relationships, responsibilities and
collaborations.
 Does not describe a concrete design or
implementation.
 Has to be well proven in some projects.
6

7. CONSEQUENCES
 Results and trade-offs of applying the pattern.
 Helpful for describe design decisions, for
evaluating design alternatives.
 Benefits of applying a pattern.
 Impacts on a system’s flexibility , extensibility or
portability.
7

8. DESCRIPTION OF DESIGN
PATTERN
 Pattern name and classification
 Intent
 Participants
 Collaborations
 Consequences
 Implementation
 Design
8

9. TYPES OF PATTERNS
 Creational patterns:
 Abstract the instantiation process
 Make a system independent to its
realization
 Class Creational use inheritance to vary
the instantiated classes
 Object Creational delegate instantiation to
an another object
9

10. CONTD…
 Structural patterns:
 Class Structural patterns concern the
aggregation of classes to form largest
structures
 Object Structural pattern concern the
aggregation of objects to form largest
structures
10

11. CONTD…
 Behavioral patterns:
 Concern with algorithms and assignment of
responsibilities between objects
 Describe the patterns of communication
between classes or objects
 Behavioral class pattern use inheritance to
distribute behavior between classes
 Behavioral object pattern use object
composition to distribute behavior between
classes 11

12. CREATIONAL PATTERN
 Singleton
 Ensure a class only has one instance
 Provide a global point of access to it
 Abstract Factory
• Provide an interface for creating families
of related or dependent objects without
specifying their concrete classes
12

13. CONTD…
 Factory Method
 Define an interface for creating an object
but let subclasses decide which class to
instantiate
 Lets a class defer instantiation to
subclasses
13

14. STRUCTURAL PATTERN
 Decorator
 Attach additional responsibilities to an object
dynamically
 Provide a flexible alternative to sub classing for
extending functionality
 Adapter
 Convert the interface of a class into another
interface clients expect
 Lets classes work together that couldn’t
otherwise because of incompatible interfaces 14

15. CONTD…
 Bridge
• Decouple an abstraction from its
implementation so that the two can vary
independently
 Façade
 Provide a unified interface to a set of
interfaces in a subsystem
 Defines an higher-level interface that
makes the system easier to use 15

16. BEHAVIORAL PATTERN
 Observer
 Define a one-to-many dependency
between objects so when one of them
change state all its dependents are
updated automatically
 Strategy
 Define a family of algorithms
 Encapsulate each one
 Make them interchangeable
 Lets the algorithms vary independently
from clients that use it 16

17. DECORATOR PATTERN
 Motivation
 Add responsibilities to individual object
not to an entire class
 conforming the interface of the
component decorated
17

18. CONTD...
 Structure Component
Operation()
ConcreteComponent
Operation()
Decorator
Operation()
ConcreteDecoratorA
Operation()
AddedState
ConcreteDecoratorB
Operation()
Addedbehavior 18

19. CONTD…
 Participants
 Component
 Define the interface for objects that can have
responsibilities added to them dinamically
 Concrete Component
 Defines an object to which additional
responsibilities can be attached
 Decorator
 Mantains a reference to a Component object and
defines an interface that conforms to Component’s
interface
 ConcreteDecorator
 Added responsibilities to the component 19

20. CONTD…
 Consequences
 More flexibility than static inheritance
 Avoids feature-laden classes high up in
the hierarchy
 A decorator and its component are not
identical
 Lots of little objects
20

21. CONTD…
 Motivation
 If you have a TextView object that
displays text in a Window
 TextView has no scroll bars by default
 TextView has no bord by default …
21

22. EXAMPLE
 Structure
VisualComponent
Draw()
TextView
Draw()
Decorator
Draw()
ScrollDecorator BorderDecorator
Draw()
ScrollTo()
ScrollPosition
Draw()
DrawBorder()
BorderWidth
22

23. BENEFITS OF DESIGN PATTERNS
 Design patterns enable large-scale reuse of
software architectures and also help document
systems
 Patterns explicitly capture expert knowledge and
design tradeoffs and make it more widely available
 Patterns help improve developer communication
 Pattern names form a common vocabulary
23

24. DRAWBACKS TO DESIGN PATTERNS
 Patterns do not lead to direct code reuse
 Patterns are deceptively simple
 Teams may suffer from pattern overload
 Patterns are validated by experience and
discussion rather than by automated testing
 Integrating patterns into a software development
process is a human-intensive activity.
24

25. THANK
YOU!!!!!!
25