Sadp Unit 4

SADP UNIT 4
DESIGN PATTERNS
SYLLABUS
1. Patterns
2. Pattern Description
3. Organizing catalogs
4. Role in solving design problem
5. Selection and Usage
6. Creational and Structural patterns
CREATIONAL PATTERNS
1. Abstract Factory
2. Builder
3. Factory method
4. Prototype
5. Singleton
STRUCTURAL PATTERNS
6. Adaptor
7. Bridge
8. Composite
9. Decorator
10. Façade
11. Flyweight
(Proxy)- 23
BEHAVIORAL PATTERNS
12. Chain of Responsibility
13. Command
14. Interpreter
15. Iterator
16. Mediator
17. Memento
18.Observer
19. State
20. Strategy
21.Template method
22.Visitor
DESIGN PATTERN
DEFINITION
"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 the same way
twice"
IN GENERAL, A PATTERN HAS
FOUR ESSENTIAL ELEMENTS:
1.The pattern name is a handle we can use to describe a design problem,
its solutions, and consequences in a word or two. Naming a pattern
immediately increases our design vocabulary. It lets us design at a higher
level of abstraction. Having a vocabulary for patterns lets us talk about them
with our colleagues, in our documentation, and even to ourselves. It makes it
easier to think about designs and to communicate them and their trade-offs
to others. Finding good names has been one of the hardest parts of
developing our catalog.
2. The problem describes when to apply the pattern. It explains the
problem and its context. It might describe specific design problems such as
how to represent algorithms as objects. It might describe class or object
structures that are symptomatic of an inflexible design. Sometimes the
problem will include a list of conditions that must be met before it makes
sense to apply the pattern.
3. The solution describes the elements that make up the design,
their relationships, responsibilities, and collaborations. The solution
doesn't describe a particular concrete design or implementation,
because a pattern is like a template that can be applied in many
different situations. Instead, the pattern provides an abstract
description of a design problem and how a general arrangement of
elements (classes and objects in our case) solves it.
4. The consequences are the results and trade-offs of applying the

pattern. Though consequences are often unvoiced when we
describe design decisions, they are critical for evaluating design
alternatives and for understanding the costs and benefits of
applying the pattern.
MVC
MVC (Model-View-Controller) is a pattern in software design commonly used
to implement user interfaces, data, and controlling logic. It emphasizes a
separation between the software’s business logic and display.
The three parts of the MVC software-design pattern can be described as

follows:
1.Model: Manages data and business logic.
2.View: Handles layout and display.
3.Controller: Routes commands to the model and view parts.
C ATA LO G O F D E S I G N PATT E R N S
Abstract Factory Provide an interface for creating families of related or
dependent objects without specifying their concrete classes.
Factory Method Define an interface for creating an object, but let

subclasses decide which class to instantiate. Factory Method lets a class
defer instantiation to classes.
Builder Separate the construction of a complex object from its

representation so that the same construction process can create different
representations.
Prototype Specify the kinds of objects to create using a prototypical

instance, and create new objects by copying this prototype.
Singleton Ensure a class only has one instance, and provide a global point
of access to it.
CATALOG OF STRUCTURAL
PATTERNS
HOW DESIGN PATTERNS
SOLVE DESIGN PROBLEMS
Finding Appropriate Objects
Determining Object Granularity
Specifying Object Interfaces
Specifying Object Implementations

HOW TO SELECT A DESIGN
PATTERN
several different approaches to finding the design pattern that's
right for your problem:
1. Consider how design patterns solve design problems. Section 1.6
discusses how design patterns help you find appropriate objects,
determine object granularity, specify object interfaces, and several
other ways in which design patterns solve design problems.
Referring to these discussions can help guide your search for the
right pattern.
2. Scan Intent sections. Section 1.4 (page 18) lists the Intent
sections from all the patterns in the catalog. Read through each
pattern's intent to find one or more that sound relevant to your
problem. You can use the classification scheme presented in Table
1.1 (page 21) to narrow your search.
3. Study how patterns interrelate. Figure 1.1 (page 23) shows
relationships between design patterns graphically. Studying these
relationships can help direct you to the right pattern or group of
patterns.
4. Study patterns of like purpose. The catalog (page 93) has three
chapters, one for creational patterns, another for structural
patterns, and a third for behavioral patterns. Each chapter starts off
with introductory comments on the patterns and concludes with a
section that compares and contrasts them. These sections give you
insight into the similarities and differences between patterns of like
purpose.
5. Examine a cause of redesign. Look at the causes of redesign
starting on page 37 to see if your problem involves one or more of
them. Then look at the patterns that help you avoid the causes of
redesign.
6. Consider what should be variable in your design. This approach
is the opposite of focusing on the causes of redesign. Instead of
considering what might force a change to a design, consider what
you want to be able to change without redesign. The focus here is
HOW TO USE A DESIGN
PATTERN
Here's a step-by-step approach to applying a design pattern
effectively:
1. Read the pattern once through for an overview. Pay particular
attention to the Applicability and Consequences sections to ensure
the pattern is right for your problem.
2. Go back and study the Structure, Participants, and
Collaborations sections. Make sure you understand the classes and
objects in the pattern and how they relate to one another.
3. Look at the Sample Code section to see a concrete example of
the pattern in code. Studying the code helps you learn how to
implement the pattern.
4. Choose names for pattern participants that are meaningful in the
application context. The names for participants in design patterns are usually
too abstract to appear directly in an application. Nevertheless, it's useful to
incorporate the participant name into the name that appears in the
application. That helps make the pattern more explicit in the implementation.
For example, if you use the Strategy pattern for a text compositing algorithm,
then you might have classes SimpleLayoutStrategy or TeXLayoutStrategy.
5. Define the classes. Declare their interfaces, establish their inheritance
relationships, and define the instance variables that represent data and object
references. Identify existing classes in your application that the pattern will
affect, and modify them accordingly.
6. Define application-specific names for operations in the pattern. Here again,
the names generally depend on the application. Use the responsibilities and
collaborations associated with each operation as a guide. Also, be consistent
in your naming conventions. For example, you might use the "Create-" prefix
consistently to denote a factory method.
7. Implement the operations to carry out the responsibilities and
collaborations in the pattern. The Implementation section offers hints to guide
you in the implementation. The examples in the Sample Code section can
help as well.
CATALOG OF BEHAVIORAL
PATTERNS

Sadp Unit 4

Uploaded by

Copyright:

Available Formats

Sadp Unit 4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sadp Unit 4

Uploaded by

Copyright:

Available Formats

SADP UNIT 4

4. The consequences are the results and trade-offs of applying the

The three parts of the MVC software-design pattern can be described as

Factory Method Define an interface for creating an object, but let

Builder Separate the construction of a complex object from its

Prototype Specify the kinds of objects to create using a prototypical

Determining Object Granularity

Specifying Object Interfaces

Specifying Object Implementations

You might also like