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();
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
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
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)