Design Pattern Slides, Slides of Design Patterns

Design Pattern Slides From The Chapter -001

Typology: Slides

2017/2018

Uploaded on 10/01/2018

unknown user
unknown user 🇵🇰

1 document

1 / 8

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
What is a Pattern?
"Each pattern describes a problem which occurs again
and 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, 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.
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 etc. It makes it easier to think about
designs and to communicate them and their trade-
offs to others.
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. Sometimes the
problem will include a list of conditions that must
be met before it makes sense to apply the pattern.
pf3
pf4
pf5
pf8

Partial preview of the text

Download Design Pattern Slides and more Slides Design Patterns in PDF only on Docsity!

What is a Pattern? "Each pattern describes a problem which occurs again and 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, 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. 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 etc. It makes it easier to think about designs and to communicate them and their trade- offs to others.
  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. Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern.
  1. 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.
  2. 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. The consequences for software often concern space and time trade-offs. They may address language and implementation issues as well. Since reuse is often a factor in object-oriented design, the consequences of a pattern include its impact on a system's flexibility, extensibility, or portability. Listing these consequences explicitly helps you understand and evaluate them.

▪ To better understand what a design pattern is, recall the process and product of design. The purpose of the design process is to determine how the eventual code will be structured or organized into modules. The output of the design process is an abstract solution model typically expressed with a symbolic modelling language such as UML.

▪ A design pattern is problem-solution pair. A design pattern provides a mapping from a specific design problem to a generic solution. ▪ Knowledge of design patterns simplifies software design by reducing the number of design problems that have to be solved from existing principles. Design problems that match documented design patterns have ready-made solutions. The remaining problems that don't match documented design patterns must be solved from existing principles.

Context : Windows are being planned for a wall. Problem : How high should the windowsill be from the floor? A windowsill that is too high cuts you off from the outside world. One that is too low could be mistaken for a door and is potentially unsafe. Solution : Design the windowsill to be 12 to 14 inches from the floor. On upper floors, for safety, make them higher, around 20 inches. The primary function of a window is to connect building occupants to the outside world. The link is more meaningful when both the ground and horizon are visible when standing a foot or two away from the window. This example illustrates some important characteristics of patterns. ▪ First, design is about balancing conflicting forces or constraints. Here the objective is to make the windowsill low enough to see the ground in order to make a connection with the outside world but high enough to be safe and not to be confused with a door.

▪ Second, design patterns provide general solutions at a medium level of abstraction. They don't give exact answers (precise measurements in the case of Window-Sill), and at the same time, they are more concrete and practical than abstract principles or strategies. In the example above, the solution is given in terms of a range of heights: 12 to 20 inches. How high to set a window will depend on preferences and local conditions. The optimal height is the value that best balances the conflicting forces. ▪ Finally, patterns aren't dogma. The pattern doesn't say that all windowsills must be 12 to 20 inches off the floor. If you are designing a jail cell, for example, there may be overriding factors that call for a windowsill higher than the recommended 12 to 20 inches.