Michael Krisper

Design Patterns
448.058 (VO)
Michael Krisper
Georg Macher

02.10.2019

This file is licensed under the Creative Commons Attribution 4.0 International (CC BY 4.0) license.
u [Link] (CC BY 4.0) Michael Krisper
Michael Krisper
Introduction

2
The Team

Michael Krisper Georg Macher In memoriam:

† Christian Kreiner
[Link]@[Link] [Link]@[Link]
Uncertainty and Risks Safety & Security
in Cyber-Security in Automotive &
Autonomous Driving

ITI - Institute for Technical Informatics

Inffeldgasse 16, 1st Floor

Bachelor’s Thesis, Master’s Thesis, Projects, Seminar, PhD

Topics Presentations on Tue, 8.10.2019 at 14:30 in NXP
Seminarroom (IE01090)
Michael Krisper
Introduction

3
Learning Goals for Course

Design Patterns Theory

• What is a design pattern? Why do we need them?
• What are principles behind design patterns?
• How to describe design patterns?
• What is a pattern language?

Application of Design Patterns

• When to use what?

Design Patterns in Detail

• Know core ideas and application of
important design patterns! (~50)
Michael Krisper
Introduction

4
Overview over all Patterns in the Course:

Message Translator
Sender A B Receiver
A B

Server A

Invoker Component 1

Client + Invoke(Message) + MethodA()

+ MethodB()
Message
Server Component
process Method Arguments
Sender Receiver boundary
pack unpack

Data Message Message Data

Header Header
Body Body
process
boundary

Logical Full Object

HalfObject1 HalfObject2

- data1 - data2

+ Service1(): data1 - data3

Client 1
+ Service2(): data2 Protocol + Service1(): data1

+ Service2(): data2 Client 2

+ Service3(): data3

process
boundary
Michael Krisper
Introduction

If you tell me, I will listen.

If you show me, I will see.
But if you let me experience, I will learn.

老子 (Lǎozǐ, 500 BC)

Michael Krisper
Goal: What is a pattern?

6
What is a pattern?
A proven solution for a (recurring) problem.

➢ But it’s not a concrete solution!

➢ A concrete solution is just one example.
➢ A Pattern is rather a solution idea, scheme, or
template.

Patterns are a universal principle:

• Economics (Etzioni, 1964)
• Social Interaction (Newell,Simon, 1972)
• Architecture (Alexander et. al., 1975)
• Software (General awareness from 1990’s on)
Michael Krisper
Goal: Purpose and Principles of Patterns

7
Purpose of Design Patterns

• Easier knowledge transfer

• Efficient problem solving by reusing existing ideas

“Don’t reinvent the wheel”

• Establishes a common vocabulary, terminology, or

language

• Increases usefulness of an idea by generalizing the

solution
Michael Krisper
Goal: What is the “standard literature”?

8
Standard Literature
• GOF: Design Patterns – Elements of Reusable Object-
Oriented Software (Gamma, Helm, Johnson, Vlissides,
1995)

• POSA1: Pattern-Oriented Software Architecture Volume 1:

A system of patterns (Buschmann, Meunier, et al., 1996)

• POSA2: Pattern-Oriented Software Architecture Volume 2:

Patterns for Concurrent and Networked Objects
(Schmidt et al., 2000)

• POSA3: Pattern-Oriented Software Architecture Volume 3:

Patterns for Resource Management (Kircher and Jain,
2004)

• POSA4: Pattern-Oriented Software Architecture Volume 4:

Pattern Language for Distributed Computing
(Buschmann, Henney, and Schmidt, 2007)
Michael Krisper
Goal: What is a pattern language?

9
Types of Design Patterns
Architectural Patterns
• Fundamental structural patterns
• Stencils for whole architectures
• Examples: Layers, Pipes-And-Filters, Broker, Model-View-
Controller, Microkernel, Async-Await

Design Patterns
• Solution templates for more isolated problems
• Examples: Composite, Adapter, Proxy, Factory

Idioms
• Fine-Grained Patterns for problems in specific programming
languages or environments
• Examples: Counted Pointer, Scoped Locking, Variadic Macros
Michael Krisper
Goal: Understand Pattern Format

10
Pattern format
• Name: A catchy name for the pattern
• Context: The situation where the problem occurs
• Problem: General Problem Description
• Forces: Requirements and Constraints - Why does the problem
hurt in this context?
• Solution: Generic Description of a proven solution.
Static Structures, Dynamic Behaviour, Actionable Steps
• Consequences (Rationale, Resulting Context):
• What are the benefits and drawbacks? Pro and Contra?
• What are the liabilities, limitations and tradeoffs?
• How are the forces resolved?
• Known-Uses: Real Life Examples
Michael Krisper
The Design Pattern House

11
The Design Pattern House
Name

Context

Problem Forces

Solution Consequences

Michael Krisper

Known Uses
Michael Krisper
Goal: Understand Pattern Format

12
Alexandrian Pattern Format
Context
Name

Solution and
Consequences

Picture
Problem and Forces

Related Patterns,
Epilogue

Excerpt from [Alexander, Christopher (1979). The Timeless Way of Building. Oxford University Press. ISBN: 978-0-19-502402-9]
Michael Krisper
Goal: Develop a design pattern

13
How Design Patterns emerge?
Design Patterns are found - not invented!
They emerge out of real use-cases/known-uses

1. Find patterns in real solutions

➔ At least three Known-Uses, Real Projects!
2. Write down the core idea and experiences
➔ Context, Problem, Forces, Solution, Consequences
3. Discuss with others (often & repeatedly)
4. Improve Pattern (and repeat discussions)
5. Publish! (Conferences, Books, Blogs)
6. Continue to improve, apply and discuss pattern
Michael Krisper
Goal: What is a pattern language?

14
Pattern Languages
… are coherent systems of patterns.

• Patterns
• Relations
• Principles (Guidelines for design and evolution):
• How to create / implement
• Beneficial combination of patterns
• How to change/evolve

Daily Life Examples: Cooking, Sports, Crafts, Sailing,

Architecture, Programming, …
Michael Krisper
Goal: Create a pattern language

15
GOF Pattern Language

Graphic from [Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995, ISBN 0-201-63361-2]
Michael Krisper
Goal: Evaluate some existing patterns

16
Layers
Split your system into layers based on abstraction levels

Michael Krisper
Michael Krisper
Goal: Evaluate some existing patterns

17
Layers
Context: Large systems that require Solution:
decomposition • Structure the function into appropriate
number of layers, based on their
abstraction levels
Problem:
• Every layer uses defined services of
• Many functions and responsibilities
sublayer
• Hard to understand structure, many • Every layer provides defined services
dependencies to upper layer

Forces: Consequences:
• Changes should be limited to one + Dependencies/Changes are kept
component local
• Clear boundaries of responsibility + Defined Interfaces between Layers
• Interfaces should be stable + Layers are exchangeable & reusable
• Parts should be exchangeable - Lower efficiency
• Parts should be reusable - No fine grained control of sublayers
• Smaller groups for easier - Changes cascade and are costly
understandability, maintainability - Right granularity is difficult to find
Michael Krisper
Goal: Evaluate some existing patterns

18
Layers – Known Uses

• Network Stack
• Virtual Machines
• API’s
• Operating Systems
• Companies
• Cities
• …
Michael Krisper
Goal: Evaluate some existing patterns

19
Layers – Implementation Issues

• Who composes the layers at runtime?

• How are Interfaces defined?

• Workarounds / Skip layers?

• Stateless / Stateful Implementations?

• Layers are Black Boxes