RAPReference Architectures and Patterns

11. Design Patterns and RefactoringDarmstadt University of Applied Sciences, Department of Computer Science

Dr. Markus Voß (Accso GmbH)

2

Today’s topic

1. Introduction

2. Reference Architecture for Business Information Systems

3. Application Kernel

4. Persistence and Transactions

5. Security (Authentication and Authorization)

6. Exception Handling

7. Client Architecture

8. Business Intelligence

9. Service-Oriented Architecture

10. Enterprise Application Integration

11. Design Patterns and Refactoring

12. Design for Testability

3

Lecture 11 (Design Patterns) concerns reference architectures on sub-application level (architecture in the small)

ApplicationLandscape

Level ofGranularity

Application

Sub-Application

9. (SOA)10. (EAI)

Lectures

2. – 7.

11.

Quasar Enterprise®

Reference

Quasar

GOF and others

<<AL>> Application Landscape<<IP>> Integration Plattform

Component types

<<A>>, <<T>>

-

4

Agenda

Introduction

Structural Software Design Patterns

Creational Software Design Patterns

Behavioral Software Design Patterns

Refactoring

Literature

5

Reminder from lecture 1: Patterns in building architecture

Goals:• Let agressors fight upwards• Keep them in parallel to the walls• Fight them from 3 sides

Solutions:• Towers off the walls• Multiple concentric bastions• Inner bastions exceed outer ones

Source: www.musoft.org

6

Definition: Design Pattern

A design pattern is a general reusable solution to a commonly occurring design

problem within a given context.

Design pattern is a general concept. It can be applied to many different fields of design - not only

software.

Example from last slide:

Goals (= Problems):• Let agressors fight upwards• Keep them in parallel to the walls• Fight them from 3 sides

Solutions (= Patterns):• Towers off the walls• Multiple concentric bastions• Inner bastions exceed outer ones

And since patterns are expressed in terms of types of objects/components and types of relationships and since patterns guide design they are (small scale) architectures.

7

History of design patterns

*) Erich Gamma; Richard Helm, Ralph Johnson, John Vlissides

• Christopher Alexanderon Towns and Buildings

1970 1980 1990 2000

• Gang of Four (GoF)*)

on Software Design

• Buschmann, Fowler, the J2EE community and others on Software Architecture

• Other authorson other topics, e.g.organization, management, …

8

The early J2EE community’s Core J2EE patterns helped structuring applications using J2EE technology

Since 2000: First generation technology J2EE

The problem to solve by the patterns is tosupport a good design using defectivetechnology

Since 2006: Next generation technology JEE

Many of the J2EE patterns became obsolete

9

Fowler‘s Enterprise Application Architecture (EAA) Patterns helpstructuring Enterprise Applications in general (organized by topic)

10

Buschmann‘s Architecture Patterns also help structuring Enterprise Applications in general

Excerpt:

• Layers• Domain Object• Explicit Interface• Encapsulated Implementation• Broker• Half-Object plus Protocol• Model-View-Controller• Database Access Layer• Active Object• Leaders/Followers• …

J2EE Community, Fowler, Buschmannetc.

Pattern-oriented approachesto software architecture

Implicit definitions of referencearchitectures using patterns assingle architectural concepts

A reference architecture can be described as a specific set of patterns

11

Patterns in general GoF

Sets of patterns are classified according to their solution scope

Software Design !

Patterns are organized in catalogs

Patterns are classified Creational (yellow), Structural (blue), Behavioral (green)

Many patterns form a pattern language (to talk about design)

Important issue

Most famous: The Gang-of-Four Patterns

Source: http://www.vincehuston.org/dp/

12

Design Pattern description according to GoF

• Pattern name and classification• Intent

• A short statement of what the pattern does• Motivation

• A scenario that illustrates where the pattern would be useful• Applicability

• Situations where the pattern can be used• Structure

• A graphical representation of the pattern• Participants

• The classes and objects participating in the pattern• Collaborations

• How do the participants interact to carry out theirresponsibilities

• Consequences• What are the pros and cons of using this pattern

• Implementation• Hints and techniques for implementing the pattern

small scalearchitecture

put incontext

13

Source information

• The diagrams and some text of the following pattern descriptions are taken from

• http://www.vincehuston.org/dp/,• http://www.eng.tau.ac.il/~eran/teaching.html and• http://en.wikipedia.org/wiki/Software_design_pattern

14

Agenda

Design Patterns

Structural Software Design Patterns

Creational Software Design Patterns

Behavioral Software Design Patterns

Refactoring

Literature

15

Overview of structural patterns from the GoF catalog

• Adapter

• Bridge

• Composite

• Decorator

• Facade

• Flyweight

• Proxy

Example

Example

Structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities

Example

16

FacadeMotivation - An example

A robot has four classes:

◦ Camera (that can identify objects)

◦ Arm (that can move)

◦ Pliers (that can grab)

◦ Operator (controlling the overall process)

Operator

Move(location)

Arm

Identify(object) : Location

Camera

open )(

close )(

Pliers

Subsystem: operator

Subsystem: mechanics

17

FacadeMotivation - Typical problems

1. How much does the operator needs to know regarding the mechanics?

2. For instance, we want to identify an object and move it to some predefined location.

Problem: No encapsulation

◦ Operator needs to know a lot: structure + behavior

◦ Preconditions

◦ Agility

oldLocation = Camera.identify(object);

Arm.move(oldLocation);

Pliers.close();

Arm.move(newLocation);

Pliers.open();

18

FacadeMotivation – Analogy of a facade

19

FacadeIntent and Applicability

Intent

◦ Provide a unified interface to a set of interfaces in a subsystem.

◦ Facade defines a higher-level interface that makes the subsystem easier to use.

Applicability

◦ Use the Facade pattern

to provide a simple, default view of a complex subsystem.

to layer your subsystems. Use a façade as the entry point to each layer.

20

FacadeStructure, Participants and Collaboration

Operator

move(location)

Arm

identify(object) : location

Camera

open()

close()

Pliers

moveObject(object, newLocation)

Facade

Operator interacts only with the Facade

class

The Facade Class knows and controls the

subsystem objects

Specific to therobot example

21

FacadeStructure, Participants and Collaboration

General description

22

FacadeStructure, Participants and Collaboration

Recursive usage

General patterns for constructing subsystems.

Each subsystem is represented by a facade interface

Inner details are encapsulated

23

FacadeConsequences

Good:

◦ Shields clients from subsystem components

◦ It promotes weak coupling between the subsystem and its clients.

◦ Facades help layer a system

Bad:

◦ Duplicated methods / redundancy

◦ Lower visibility of subsystem functionality

24

FacadeAnother example: The application kernel facade

Shields dialogs (client) from A components (server)

Promotes weak coupling between these two

Helps layer the system

Dialogs and clients can evolve more independently

Multiple versions of clients are possible

see lecture #3

25

Composite

An abstract base class (Component) specifies the uniform behavior.

Primitive (Leaf) and Composite classes are subclassed.

Composite manages components uniformly, using add and remove.

Intent: Compose objects into tree structures to represent whole-part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. [GoF, p163] .

26

Adapter

Intent: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. [GoF, p139].

Object Adapter Class Adapter

27

Agenda

Introduction

Structural Software Design Patterns

Creational Software Design Patterns

Behavioral Software Design Patterns

Refactoring

Literature

28

Overview of creational patterns from the GoF catalog

• Abstract Factory

• Builder

• Factory Method

• Prototype

• Singleton

Example

Example

Creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The

basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow

controlling this object creation.

29

Factory

A factory is an object for creating other objects (then called products). It is an abstraction of a constructor. It typically has a method for every kind of object it is

capable of creating. Factories are used in situations where getting hold of an object of a particular kind is a more complex process than simply creating a new object.

The factory object might decide to create the object's class (if applicable) dynamically, return it from an object pool, do complex configuration on the object,

or other things.

Factory Productcreate

30

Pattern: Factory Method

Intent: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. [GoF, p107]

Factory

Factory Method

31

Pattern: Abstract Factory

Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes. [GoF, p87]

Family (multiple)

32

Agenda

Introduction

Structural Software Design Patterns

Creational Software Design Patterns

Behavioral Software Design Patterns

Refactoring

Literature

33

Overview of behavioral patterns from the GoF catalog

• Chain of Responsibility

• Command

• Interpreter

• Iterator

• Mediator

• Memento

• Observer

• State

• Strategy

• Template Method

• Visitor

Example

Behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so,

these patterns increase flexibility in carrying out this communication

34

Observer

Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. [GoF, p293]

View = Observer ?

GUI-Pattern: Close, but not the same:• Model-View-Controller (MVC)• Model-View-ViewModel (MVVM)• …

35

Design Patterns - Epilog

• Design Patterns are around for quite some years now

• This is why many of them already became widely used best practices in professional software development

• But even the advanced practitioner should step back every now and then to look at the original definitions and review the basic concepts

36

Agenda

Introduction

Structural Software Design Patterns

Creational Software Design Patterns

Behavioral Software Design Patterns

Refactoring

Literature

37

One of the most important non-functional attributes of software is understandability

Any fool can write code that a computer can understand.

Good programmers write code that humans can

understand.

Martin Fowler: Refactoring

38

Bad Code

Winner of the "20C7: 20th Chaos Communication Congress Compact C Coding Contest"

http://www.ulm.ccc.de/old/shortest/20c7/

What is the semantic of this program?

Solution: see

http://www.ulm.ccc.de/old/shortest/20c7/aufgabe.html

39

Catalog for refactorings by Martin Fowler:http://www.refactoring.com/catalog/ R

40

Selected refactoringssome examples

Composing Methods Extract Method

Moving Features between Objects Move Method

Organizing Data Replace Type Code with State/StrategyReplace Magic Number with Symbolic Constant

Simplifying Conditional Expressions Replace Conditional with Polymorphism

Making Method Calls Simpler Separate Query from ModifierParameterize Method

Dealing with Generalization Replace Inheritance with DelegationPull Up Field , Pull Up MethodExtract InterfaceCollapse Hierarchy

R

41

Selected refactorings:Composing Methods R

42

Selected refactorings:Moving features between objects R

43

Selected refactorings:Dealing with Generalization R

44

Refactoring and its relation to design patterns

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without

changing its external behavior, undertaken in order to improve some of the non-functional

attributes of the software.

• While design patterns describe good practices of design (idealistic static view),refactoring assumes design to usually be sub-optimal and a constant subject to change (realistic dynamic view)

• Refactoring can take place• Without changing the structure imposed by already used patterns• In order to arrive at code structures according to desired design patterns• Even changing the software architecture

Clash of cultures in architecture definition: Top-down vs. evolutionary

45

Agenda

Introduction

Structural Software Design Patterns

Creational Software Design Patterns

Behavioral Software Design Patterns

Refactoring

Literature

46

Literature

On Design Patterns

• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley Longman, Amsterdam; Auflage: 1st ed., Reprint. (31. Oktober 1994)

On Refactoring

• Martin Fowler: Refactoring: Improving the Design of Existing Code. Addison-Wesley Longman, Amsterdam; Auflage: illustrated edition (28. Juni 1999)