1 Chapter 5:Design Patterns. 2 What are design pattern?  Schematic description of design solution to recurring problems in software design and,  Reusable.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Welcome to. Who am I? A better way to code Design Patterns ???  What are design patterns?  How many are there?  How do I use them?  When do I use.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Chapter 6: Using Design Patterns
(c) 2009 University of California, Irvine – André van der Hoek1June 13, 2015 – 21:42:16 Informatics 122 Software Design II Lecture 8 André van der Hoek.
Design Patterns CS is not simply about programming
Design Patterns. What are design patterns? A general reusable solution to a commonly occurring problem. A description or template for how to solve a problem.
Design Patterns – Part 3 Sources:
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Design Patterns.
(c) 2010 University of California, Irvine – André van der Hoek1June 29, 2015 – 08:55:05 Informatics 122 Software Design II Lecture 8 André van der Hoek.
Design Patterns Module Name - Object Oriented Modeling By Archana Munnangi S R Kumar Utkarsh Batwal ( ) ( ) ( )
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns.
Chapter 22 Object-Oriented Design
PRESENTED BY SANGEETA MEHTA EECS810 UNIVERSITY OF KANSAS OCTOBER 2008 Design Patterns.
Design Patterns academy.zariba.com 1. Lecture Content 1.What are Design Patterns? 2.Creational 3.Structural 4.Behavioral 5.Architectural 6.Design Patterns.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Design Patterns Ric Holt & Sarah Nadi U Waterloo, March 2010.
Programming With Java ICS201 University Of Hail1 Chapter 12 UML and Patterns.
Design Patterns Alan Shalloway, James Trott, Design Patterns Explained, Addison-Wesley, Gamma, Helm, Johnson, Vlissides, Design Patterns, Elements.
Design Patterns.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns Part 1.
Draw a small class diagram (2 or 3 classes) for each of the following examples: For Netflixs, you have to keep track of the movie details AND the copies.
SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Objectives Lecture 11 : Frameworks SWE 316: Software Design and Architecture  To understand.
Design patterns. What is a design pattern? Christopher Alexander: «The pattern describes a problem which again and again occurs in the work, as well as.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns 1.
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
CSC 211 Introduction to Design Patterns. Intro to the course Syllabus About the textbook – Read the introduction and Chapter 1 Good attendance is the.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
Object-Oriented Design Principles and Patterns. © 2005, James R. Vallino2 How Do You Design? What principles guide you when you create a design? What.
18 April 2005CSci 210 Spring Design Patterns 1 CSci 210.
L11-12: Design Patterns Definition Iterator (L4: Inheritance)‏ Factory (L4: Inheritance)‏ Strategy (L5: Multiple Inheritance)‏ Composite (L6: Implementation.
Software Design Patterns (1) Introduction. patterns do … & do not … Patterns do... provide common vocabulary provide “shorthand” for effectively communicating.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns.
Chapter 8 Object Design Reuse and Patterns. Object Design Object design is the process of adding details to the requirements analysis and making implementation.
Patterns COM379 University of Sunderland James Malone.
Design Principle & Patterns by A.Surasit Samaisut Copyrights : All Rights Reserved.
Structural Design Patterns
ECE450S – Software Engineering II
CSE 240 Lecture 9. © Lethbridge/Laganière 2001 Chapter 5: Modelling with classes2 Overview Chapter 6 Start on Chapter 7 if time permits.
Introduction to Design Patterns Part 1. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns2 Patterns - Architectural Architectural Patterns:
Design Patterns By Mareck Kortylevitch and Piotreck Ratchinsky.
Design Pattern. Definition: A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
Software Design Patterns Curtsy: Fahad Hassan (TxLabs)
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns.
Design Patterns. 1 Paradigm4 Concepts 9 Principles23 Patterns.
Design Patterns Software Engineering CS 561. Last Time Introduced design patterns Abstraction-Occurrence General Hierarchy Player-Role.
Design Patterns Introduction
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Subtopics: 1. Frameworks :Reusable systems 2. Design Patterns 1.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
TEMPLATE METHOD DESIGN PATTERN -SWAPNIL SHAH. WHAT IS A DESIGN PATTERN… A design pattern is a general reusable solution to a commonly occurring problem.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns.
Design Patterns: MORE Examples
Design Patterns (Chapter 6 of Text Book – Study just 8)
Chapter 6: Using Design Patterns
Chapter 10 Design Patterns.
Chapter 5:Design Patterns
Software Design Patterns
MPCS – Advanced java Programming
Introduction to Design Patterns
Design Patterns.
CMPE 135: Object-Oriented Analysis and Design October 24 Class Meeting
Design Patterns with C# (and Food!)
object oriented Principles of software design
Chapter 6: Using Design Patterns
Introduction to Design Patterns Part 1
CMPE 135 Object-Oriented Analysis and Design March 21 Class Meeting
Chapter 8, Design Patterns Introduction
Presentation transcript:

1 Chapter 5:Design Patterns

2 What are design pattern?  Schematic description of design solution to recurring problems in software design and,  Reusable (i.e. generic) but don’t have to be implemented in the same way  Describe problems that occur repeatedly and core solutions to those problems

3 Why design pattern?  To capture & document software design knowledge  To support reuse in design and boost confidence in software systems  To provide common vocabulary for software designers to communicate their designers

4 Useful of design pattern  Reuse existing, high quality solutions to recurring design patterns  Improve future design: solution to new problems can be obtained with higher quality  Improve documentation: smaller & simpler  Use a right design, not just one that works

5 Pattern category  Divided into three:-  Creational: creation of object  Structural: concern about the composition of objects into larger structures  Behavioral: define how object interact and how responsibility is distributed among them (i.e. use inheritance, aggregation & composition).

6 Pattern category CreationalStructuralBehavioral Abstract factoryAdapterChain of responsibility BuilderBridgeCommand Factory methodCompositeInterpreter PrototypeDecoratorIterator SingletonFacadeMediator FlyweightMemento ProxyObserver State Strategy Template method Visitor

7 Pattern description  Divided into seven:-  Content: General situation in which the pattern applies  Problem: A short sentence or two string the main difficulty  Forces: The issues or concerns to consider when solving the problem  Solution: The recommended way to solve the problem in the given context  Antipatterns: Solutions that are inferior or do not work in this context  Related patterns: Patterns that are similar to this pattern  References: Who developed or inspired the pattern

8 The abstraction – occurrence pattern  Context  Often in a domain model you find a set of related objects (occurrence)  Problem  What is the way to represent such set of occurrences in a class diagram?  Forces  You want to represent the members of each set of occurrences without duplicating the common information

9 Abstraction – Occurrence Solution:

10 Abstraction – Occurrence Antipatterns:

11 The general hierarchy pattern  Context  Often in a hierarchy can have one or more objects above them (superiors)  Problem  How to you represent a hierarchy of objects, in which some objects cannot have subordinates?  Forces  You want a flexible way of representing the hierarchy  All the objects have many common properties & operations

12 General hierarchy Solution:

13 General hierarchy Solution:

14 General hierarchy Antipattern:

15 The Player – Role Pattern  Context  A role is a particular set of properties associated with an object in a particular context  An object may play different roles in different contexts  Problem  How do you best model players and roles so that a player can change roles or process multiple roles?  Forces  It is desirable to improve encapsulation by capturing the information associated with each separate role in a class  You want to avoid multiple inheritance  You cannot allow an instance to change data

16 The Player – Role Pattern Solution:

17 The Player – Role Pattern Example 1:

18 The Player – Role Pattern Example 2:

19 The singleton pattern  Context  It is very common to find classes for which only one instance should exist (singleton)  Problem  How do you ensure that it is never possible to create more than one instance of singleton class?  Forces  The use of a public constructor cannot guarantee that no more than one instance will be created  The singleton instance must also be accessible to all classes that require it

20 The singleton pattern Solution:

21 The observer pattern  Context  When an association is created between two classes, the code for the classes becomes inseparable  If you want to reuse one class, then you also have to reuse the other  Problem  How do you reduce the interconnection between classes, especially between classes that belong to different modules or subsystems?  Forces  You want to minimize the flexibility of the system to the greatest extent possible

22 The observer pattern Solution:

23 Observer  Antipatterns  Connect an observer directly to an observable so that they both have references to each other  Make the observers subclasses of the observable

24 The delegation pattern  Context  When an association is created between two classes, the code for the classes becomes inseparable  If you want to reuse one class, then you also have to reuse the other  Problem  How do you reduce the interconnection between classes, especially between classes that belong to different modules or subsystems?  Forces  You want to minimize the flexibility of the system to the greatest extent possible

25 The delegation pattern Solution:

26 The delegation pattern Example:

27 The adapter pattern  Context  You are building an inheritance hierarchy and want to incorporate it into an existing class  The reused class is also often already part of its own inheritance hierarchy  Problem  How to obtain the power of polymorphism when reusing a class whose method  Have the same function  But not the same signature  Forces  You do not have access to multiple inheritance or you do not want to use it

28 The adapter pattern Solution:

29 The adapter pattern Example:

30 The façade pattern  Context  Often, an application contains several complex packages  A programmer working with such packages has to manipulate many different classes  Problem  How do you simplify the view that programmers have of a complex package  Forces  It is hard for a programmer to understand and use an entire subsystem  If several different application classes call method of the complex package, then any modifications made to the package will necessitate a complex review of all these classes

31 The façade pattern Solution:

32 The factory pattern  Context  A reusable framework needs to create objects, however the class the created objects depends on the application  Problem  How do you enable a programmer to add new application specific class into a system built on such as framework?  Forces  We want to have the framework create and work with application-specific classes that the framework does not yet know about

33 The factory pattern Solution

34 The factory pattern Example