Design Patterns Credits: Xiaochuan Yi, U of Georgia Nenad - - PowerPoint PPT Presentation

▶
design patterns
SMART_READER_LITE
LIVE PREVIEW

Design Patterns Credits: Xiaochuan Yi, U of Georgia Nenad - - PowerPoint PPT Presentation

Jan 19, 2024 137 likes •405 views

Design Patterns Credits: Xiaochuan Yi, U of Georgia Nenad Medvidovi Sommerville, Chapter 18 dofactory.com Instructor: Peter Baumann email: p.baumann@jacobs-university.de tel: -3178 office: room 88, Research 1 CONGRESS.SYS Corrupted:

slide-1
SLIDE 1

320312 Software Engineering (P. Baumann)

Design Patterns

Instructor: Peter Baumann email: p.baumann@jacobs-university.de tel:

  • 3178
  • ffice:

room 88, Research 1 Credits: Xiaochuan Yi, U of Georgia Nenad Medvidović dofactory.com Sommerville, Chapter 18

CONGRESS.SYS Corrupted: Re-boot Washington D.C. (Y/n)?

slide-2
SLIDE 2

2 320312 Software Engineering (P. Baumann)

Introduction to Design Patterns

  • Be a good programmer
  • …and an efficient one – learn from others!
  • Similar patterns occur over and over
  • Do not reinvent the wheel
  • Sharing knowledge of problem solving
  • Facilitate communication between programmers
  • Write elegant and graceful code
  • Computer programming as art [Donald Knuth]
  • See conceptual beauty
slide-3
SLIDE 3

3 320312 Software Engineering (P. Baumann)

Semiotics: Aspects of Language Use

  • Syntax
  • - how to write it (grammar)
  • Ex:

if ( condition ) statement; if [ condition ]; then statement; fi

  • Semantics
  • - what to express (how it is evaluated)
  • Ex:

conditional evaluation

  • Pragmatics
  • - how to apply
  • Ex:

"goto considered bad"

  • Meta language
  • - describe the language of discourse
  • Ex:

BNF grammars www.cs.sfu.ca/~cameron/Teaching/383/syn-sem-prag-meta.html

slide-4
SLIDE 4

4 320312 Software Engineering (P. Baumann)

Design Patterns

  • pattern =

description of the problem and the essence of its solution

  • should be sufficiently abstract to be reused in different settings
  • often rely on object characteristics such as inheritance and polymorphism
  • design pattern =

way of re-using abstract knowledge about a (sw) design problem and its solution

slide-5
SLIDE 5

5 320312 Software Engineering (P. Baumann)

History of Design Patterns

  • Architect: Christopher Alexander
  • A Pattern Language (1977)
  • A Timeless Way of Building (1979)
  • “Gang of four”
  • Erich Gamma
  • Richard Helm
  • Ralph Johnson
  • John Vlissides
  • Design Patterns: Elements of Reusable Object-Oriented Software (1995)
slide-6
SLIDE 6

6 320312 Software Engineering (P. Baumann)

Design Patterns in Architecture

  • First used in architecture [C. Alexander]
  • Ex. How to create

a beer hall where people socialize?

slide-7
SLIDE 7

7 320312 Software Engineering (P. Baumann)

Design Patterns in Architecture

(181) The Fire (8) Mosaic of Subcultures (179) Alcoves (95) Building Complex (33) Night Life (31) Promenade (90) Beer Hall Cities & T

  • wns

Interiors Local Gatherings

slide-8
SLIDE 8

8 320312 Software Engineering (P. Baumann)

Pattern Elements

  • Name
  • A meaningful pattern identifier
  • Description
  • Problem / Applicability description
  • Solution description
  • Not concrete design but template for design solution

that can be instantiated in different ways

  • Consequences
  • The results and trade-offs of applying the pattern
slide-9
SLIDE 9

9 320312 Software Engineering (P. Baumann)

  • Name
  • Singleton
  • Description
  • Ensure a class has only one instance and provide a global point of access to it
  • Problem / Applicability
  • Used when only one object of a kind may exist in the system
  • Solution
  • defines an Instance operation that lets clients access its unique instance
  • Instance is a class operation
  • responsible for creating and maintaining its own unique instance

Patterns by Example: Singleton

slide-10
SLIDE 10

10 320312 Software Engineering (P. Baumann)

Singleton Code

// Singleton pattern --Structural example class Singleton { public: static Singleton* Instance() { static Singleton instance; return &instance; } private: Singleton() {} } int main() { // Constructor is protected, cannot use new Singleton *s1 = Singleton::Instance(); Singleton *s2 = Singleton::Instance(); Singleton *s3 = s1->Instance(); Singleton &s4 = *Singleton::Instance(); if( s1 == s2 ) cout << "same instance" << endl; }

slide-11
SLIDE 11

11 320312 Software Engineering (P. Baumann)

class LoadBalancer { private: LoadBalancer() { add_all_servers; } public: static LoadBalancer *GetLoadBalancer() { // thread-safe in C++ 11 static LoadBalancer balancer; return &balancer; } … }

Singleton Application

// SingletonApp test LoadBalancer *b1 = LoadBalancer::GetLoadBalancer(); LoadBalancer *b2 = LoadBalancer::GetLoadBalancer(); if( b1 == b2 ) cout << "same instance" << endl;

slide-12
SLIDE 12

12 320312 Software Engineering (P. Baumann)

Singleton, Revisited

// Singleton pattern class Singleton { public: static Singleton* Instance() { static Singleton instance; return &instance; } private: Singleton() {} }

Problems:

  • Subclassing
  • Copy constructor
  • Destructor: when?
  • Static vs. heap

// Singleton -- modified example class Singleton { public: static Singleton* Instance() { static Singleton instance; return &instance; } private: Singleton() {} Singleton(const Singleton&); Singleton& operator=(const Singleton&); }

slide-13
SLIDE 13

13 320312 Software Engineering (P. Baumann)

Multiple displays enabled by Observer

Subject A: 40 B: 25 C: 15 D: 20 Observer 1 Observer 2

50 25 A B C D A B C D

slide-14
SLIDE 14

14 320312 Software Engineering (P. Baumann)

  • Name
  • Observer
  • Description
  • Separates the display of object state from the object itself
  • Problem / Applicability
  • Used when multiple displays of state are needed
  • Solution
  • See slide with UML description
  • Consequences
  • Optimizations to enhance display performance are impractical

The Observer Pattern

slide-15
SLIDE 15

15 320312 Software Engineering (P. Baumann)

The Observer pattern

Subject Observer Attach (Observer) Detach (Observer) Notify () Update () ConcreteSubject GetState () subjectState ConcreteObserver Update ()

  • bserverState

return subjectState for all o in observers

  • -> Update ()
  • bserverState =

subject -> GetState ()

slide-16
SLIDE 16

16 320312 Software Engineering (P. Baumann)

  • Description
  • Define an object that encapsulates how a set of objects interact
  • Mediator promotes loose coupling by keeping objects from referring to each other explicitly
  • Problem / Applicability
  • Complex interaction exists
  • Consequences
  • Limits subclassing; Decouples colleagues; Simplifies object protocols; Abstracts how objects

cooperate; Centralizes control

The Mediator Pattern

slide-17
SLIDE 17

17 320312 Software Engineering (P. Baumann)

  • Description
  • Provides a unified interface to

a set of interfaces in a subsystem

  • Defines a higher-level interface

that makes subsystem easier to use

  • Applicability
  • Need to provide a simple interface to a complex system
  • Need to decouple a subsystem from its clients
  • Need to provide an interface to a software layer
  • Consequences
  • Shields clients from subsystem components
  • Promotes weak coupling between the subsystem and its clients

The Façade Pattern

slide-18
SLIDE 18

18 320312 Software Engineering (P. Baumann)

The Proxy Pattern

  • Description
  • Provide a surrogate or placeholder for another object to control access to it
  • Problem / Applicability
  • Remote proxies can hide the fact that a real object is in another address space
  • Virtual proxies can create expensive objects on demand
  • Protection proxies can control access to an object
  • Smart references can perform additional action above a simple pointer
slide-19
SLIDE 19

19 320312 Software Engineering (P. Baumann)

The Adapter Pattern

  • Description
  • Adapter lets classes work together

that could not otherwise because of incompatible interfaces

  • Problem / Applicability
  • Need to use an existing class whose interface does not match
  • Need to make use of incompatible classes
  • Consequences
  • Class adapter commits to the concrete Adapter class
slide-20
SLIDE 20

20 320312 Software Engineering (P. Baumann)

Adapter: Another View [Wikipedia]

slide-21
SLIDE 21

22 320312 Software Engineering (P. Baumann)

Composite Pattern

  • Definition
  • Compose objects into tree structures to represent part-whole hierarchies
  • Composite lets clients treat individual objects and compositions of objects uniformly
  • Problem / Applicability
  • Any time there is partial overlap in the capabilities of objects
slide-22
SLIDE 22

23 320312 Software Engineering (P. Baumann)

Composite Pattern UML Diagram

slide-23
SLIDE 23

29 320312 Software Engineering (P. Baumann)

  • Creational
  • Abstract Factory

Creates an instance of several families of classes

  • Builder

Separates object construction from its representation

  • Factory Method

Creates an instance of several derived classes

  • Prototype

A fully initialized instance to be copied or cloned

  • Singleton

A class of which only a single instance can exist

  • Structural Patterns
  • Adapter

Match interfaces of different classes

  • Bridge

Separates an object’s interface from its implementation

  • Composite

A tree structure of simple and composite objects

  • Decorator

Add responsibilities to objects dynamically

  • Façade

A single class that represents an entire subsystem

  • Flyweight

A fine-grained instance used for efficient sharing

  • Proxy

An object representing another object

Types of Patterns

slide-24
SLIDE 24

30 320312 Software Engineering (P. Baumann)

  • Behavioral Patterns
  • Chain of Resp.

A way of passing a request between a chain of objects

  • Command

Encapsulate a command request as an object

  • Interpreter

A way to include language elements in a program

  • Iterator

Sequentially access the elements of a collection

  • Mediator

Defines simplified communication between classes

  • Memento

Capture and restore an object's internal state

  • Observer

A way of notifying change to a number of classes

  • State

Alter an object's behavior when its state changes

  • Strategy

Encapsulates an algorithm inside a class

  • Template Method

Defer the exact steps of an algorithm to a subclass

  • Visitor

Defines a new operation to a class without change

Types of Patterns (contd.)

slide-25
SLIDE 25

31 320312 Software Engineering (P. Baumann)

Summary

  • Design patterns = generic, re-usable design templates for OOP
  • Code templates, to be adapted by programmer
  • Faster, safer implementation through re-use
  • three types of patterns: creational, structural, and behavioral
  • Design pattern catalog
  • http://www.dofactory.com/net/design-patterns#list
  • It‘s practice – show it in interviews!