ict inf5120 – modellbasert systemutvikling f10-1: adm, architectural patterns, design patterns and...

94
ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

Upload: edwina-lane

Post on 25-Dec-2015

218 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

INF5120 – Modellbasert Systemutvikling

F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring 

Forelesning 12.04.2010

Arne-Jørgen Berre

Page 2: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 2

INF5120 - Lecture plan - 2010 1: 25/1: Introduction to MBSU, MDA, OO and Service/SOA modeling, Overall EA, 4 parts: MDE/SSS/MS/MDI

(AJB)

Part I: MDE – Model Driven Engineering 2: 1/2: MDE I: Metamodeling. DSL and UML profiles, MDA technologies (XMI, Eclipse, EMF/GMF) (AJB/BRE)

Part II: SSS – Service Science and Service/SOA technologies 3: 8/2: SSS I: Service science (top down) - Service and SOA Technologies (bottom up) (AJB)

Part I continued: MDE – Model Driven Engineering 4: 15/2: MDE II: Model transformations with MOFScript, ATL and other technologies (GO/JO) 5 :22/2: MDE III: Code generation with MOFScript, ATL and other technologies (GO/JO)

Part III: MOS – Modeling of Services - with SoaML 6: 1/3: MOS I: Business Process Modeling (CIM) - with BPMN 2.0, and BMM, EA with UPDM (AJB) 7: 8/3: MOS II: Soaml, UML2 and SysML, Modelio SOA and Scope, –Collaboration and Component models (AJB) 8: 15/3: MOS III: SoaML (PIM) and Requirements modeling , CIM->PIM and SoaML (AJB) 9: 22/3: MOS IV: Method Engineering and SPEM / EPF - for Service systems (BRE)

EASTER Part IV – Model Driven Interoperability 10: 12/4: MS V: SOA and Service Design, MDA and ADM - Intro to MDI (AJB ) 11: 19/4: MDI I: Semantic Web with Ontologies and Model Driven Interoperability (TIR) 12: 26/4: MDI II: Semantic Services and Model Driven Interoperability (TIR) 13: 3/5: MDE IV: Evolution and industrial practice of modelbased technologies (AJB++)

14: 10/5: Course summary and preparation for Exam 31/5 (AJB)

Exam: May 31st, 2010 (Monday), 0900-1200 (3 hours)

Page 3: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Agenda

ADM Architecture Driven Modernisation

Patterns GRASP patterns Design principles Design Patterns Refactoring 

Page 4: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

ADM – Architecture-Driven Modernization (Reverse MDA)

Page 5: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

IT Architecture

Page 6: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Business Architecture

Page 7: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Data(What)

Function(How)

Network(Where)

People(Who)

Time(When)

Motivation(Why)

Scope(Contexts)

Business(Concepts)

System(Logic)

Technology(Physics)

Component(Assemblies)

List of thingsimportant

to business

List of processesthat the business

performs

List of locationswhich the business

operates

List of organizationsimportant to the

business

List of events/cyclesimportant to the

business

List of businessgoals/strategies

Semantic ModelBusinessProcessModel

BusinessLogisticsSystem

WorkflowModel

MasterSchedule

BusinessPlan

Logical Data ModelApplicationArchitecture

DistributedSystem

Architecture

HumanInterface

Architecture

ProcessStructure

Business RuleModel

Physical Data Model System DesignTechnologyArchitecture

PresentationArchitecture

ControlStructure

RuleDesign

Data Definition ProgramNetwork

ArchitectureSecurity

ArchitectureTiming

DefinitionRule

Definition

Operation(Instances)

Data Function Network Organization Schedule Strategy

BMM

SBVR

VDM OSMSBVR

DTFV

BPMN

UMLIMM(CWM)

CMPM

SoaML

ODM

Business architecture models in OMGin the Zachman framework

Page 8: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

IT Architecture Ecosystem

Page 9: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

IT/Business architecture transformation

Page 10: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Modernization horse shoe model

Page 11: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Modernization scenarios

Page 12: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

ADM Framework

Page 13: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

ADM Standards in OMG

Page 14: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

KDM & ASTM

Page 15: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Pattern Recognition and SMM

Page 16: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Visualisation, Refactoring and Transformation

Page 17: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Convergence to Cloud Computing

Adaptive Data Centers

IBM, HP, Sun

Infrastructureas a Service

Amazon.com

CloudComputing

VirtualizationVMware, Citrix

Software as a Service

Saleforce.com

Platform as a ServiceGoogle, Microsoft

Utility Computing

Rackspace, Terremark, Savvis, IBM

GridsUniva Ud,

Gigaspaces, IBM

Enterprise AppsMicrosoft, IBM, Oracle,

Tibco

Desktop as a Service

Simtone, Desktone

Desktop Apps

Google, Zoho

Page 18: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Cloud Computing DefinitionCloud Computing Definition“Cloud computing is a model for enabling convenient, on-demand

network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with

minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models”.

5: On-demand self-service, Broad network access, Resource pooling, Rapid elasticity, Measured Service

3: IaaS, PaaS, SaaS

4: Private, Community, Public, Hybrid

NIST

Definition of Cloud Computing, Draft version 15, Oct 7, 2009

http://csrc.nist.gov/groups/SNS/cloud-computing/index.html

Page 19: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Government Cloud Framework

Page 20: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Service Model OverviewService Model Overview

SaaS

To use the provider’s applications running on a cloud infrastructure and accessible from various client

devices through a thin client interface such as a Web browser

Citizen Engagement (Wikis, Blogs, Data.gov)

Government Productivity (Cloud based tools)

Business Enablement (Salesforce.com)

Enterprise Applications (Core Mission & Business Svcs

PaaS

To deploy onto the cloud infrastructure consumer-created applications using programming languages

and tools supported by the provider (e.g., java, python, .Net)

Database and Database Management Systems

Developer / Testing Tools Virtual Environments

IaaS

To provision processing, storage, networks, and other fundamental computing resources where the

consumer is able to deploy and run arbitrary software, which can include operating systems and

applications

• Computing• Storage

• Application hosting

Model Capability Provided Example Services

Page 21: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

REMICS Overall process

Recover

Legacy Artifacts

Source Architecture Migrate

Target Architecture for Service

Cloud platform

Forward MDA through

PIM4Cloud

Service Cloud

Implementation

Model Driven Interoperability

Validate, Control and Supervise

Knowledge: REMICS KDMBusiness Process and Rules

Components: SoaMLImplementation: UML, U2TP

Knowledge Discovery,Reverse Engineering

Source code, binaries, documentation, users

knowledge, configuration files, execution logs and traces.

SOA and Cloud Computing Patterns applied,

Legacy Components Replacement and Wrapping,

Design by Service Composition

Service mediation for adaptation

SoaML with REMICS extensions for Service Clouds,

Links to Business Models

Model Transformation, Code Generation, Traceability

RESERVOIR, Joyant, Amazon, Google, Microsoft

Models@Runtime for application management,

Model Checking, Model-based Testing for validation

Page 22: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

REMICS Metamodel extensions

Page 23: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Analysis(Domain)Patterns

Architecture Patterns (Macro Architecture)

Design Patterns (Micro Architecture)

Domain Framework

(OO) Reusable Components

Analysis Design Implementation

Idioms(Language dependent patterns)

Patterns: From Analysis to Implementation

Page 24: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Patterns on various design levels

Object level patterns: GRASP

Collaboration level patterns: Design Patterns

Module level patterns: Architecture Patterns

Refacto

ring

Page 25: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

General Responsibility Assignment

Software Patterns.

Responsibility assignment.1. knowing (answering)

2. or, doing

Guidance and evaluation in mechanistic design.

1. Expert1. Expert2. Creator2. Creator3. Controller3. Controller4. Low Coupling4. Low Coupling5. High Cohesion5. High Cohesion6. Polymorphism6. Polymorphism7. Pure Fabrication7. Pure Fabrication8. Indirection8. Indirection9. Don’t Talk to 9. Don’t Talk to StrangersStrangers

Page 26: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Patterns – Abstract Factory

Page 27: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Design patterns (with UML & Java examples)

Based on: Gamma/Helm/Johnson/Vlissides (GoF): Design Patterns, 1995

R. Ryan:, D. Rosenstrauch:Design Patterns in Java, 1997

Based on: Gamma/Helm/Johnson/Vlissides (GoF): Design Patterns, 1995

R. Ryan:, D. Rosenstrauch:Design Patterns in Java, 1997

Page 28: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 28

What are patterns?

"A solution to a problem in a context"? Insufficient, says the “Gang of Four” (GOF) What’s missing? 3 things:

Recurrence Teaching (e.g., implementation consequences, trade-offs, and variations) A name

GOF: Patterns contain 4 essential elements

pattern name problem solution consequences

Christopher Alexander (as quoted in the GOF book): "Each pattern describes a problem which occurs over and over again ... and then

describes the core of [a] solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

Page 29: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Design PatternDesign Pattern

A design pattern describes a basic scheme for structuringsubsystems and components of a software architecture aswell as their relationships. It identifies, names, and abstractsa common structural or functional principle by describingits different parts, their collaboration and responsibilities.

Page 30: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

GOF (Gang of Four) 23 Patterns

Creational Patterns (5) Abstract FactoryAbstract Factory, Builder, Factory Method, Prototype,

Singleton Structural Patterns (7) Adapter, Bridge, CompositeComposite, Decorator, Façade,

Flyweight, Proxy Behavioural Patterns (11) Chain of responsibility, Command, Interpreter,

Iterator, Mediator, Memento, ObserverObserver, State, Strategy, Template method, Visitor

Page 31: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 31

Skylight Spelunker

“Skylight Spelunker” is a Java framework for a file browser similar in appearance to the “Windows Explorer” included with Windows 98.

Spelunker has two views: Disks and folders in tree structure (FolderView - Left pane) All contents of selected folder (ContentsView - Right pane)

Spelunker provides support for : Multiple ways of arranging ContentsView icons Accessing network drives as well as local Deleting, renaming and viewing disk contents

Page 32: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 32

Windows Explorer Screen Shot

FolderView ContentsView

Page 33: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 33

Patterns in Spelunker example

Composite used to model the file tree data structure

Strategy used to layout the file and folder icons in ContentsView

Observer used to re-display FolderViews and ContentsViews after user

requests

Proxy and State used to model password-protected network disk drives

Command used to carry out user requests

Page 34: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 34

The “Composite” pattern

Problem What is the best way to model the Spelunker file tree?

The Spelunker file tree is a classic tree structure. Thus we need a leaf class (File) and a tree class (Folder) which contains pointers to the Files and Folders in it.

However, there are many operations that are relevant to both a File and a Folder (e.g., getSize()).

The user doesn’t treat Files and Folders differently, so why should calling modules have to?

The design would be less complex and more flexible if the calling module could initiate operations on a target object, without knowing whether the target was a File or a Folder.

File and Folder should share a common interface.

Page 35: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 35

The “Composite” pattern

How the pattern solves the problem Intent

“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” [GHJV94]

Explanation The Composite pattern works by having leaf and tree objects share a

common interface. Create an abstract base class (or interface) that represents both File

and Folder. Files and Folders need to provide implementations for the same

operations, but they can implement them differently. E.g., leaves usually handle an operation directly, while trees usually forward

the operation to its children (and/or perform additional work before or after forwarding)

Page 36: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 36

The “Composite” pattern

How the pattern solves the problem, cont. Gang of Four UML [GHJV94]

children

Leaf

Operation( )

Client

Composite

Operation( )Add(Component)Remove(Component)GetChild(int)

Component

Operation( )Add(Component)Remove(Component)GetChild(int)

for all g in children g.Operation();

Page 37: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 37

The “Composite” pattern

Use of the pattern in Spelunker Both File and Folder share a common interface: Node. Spelunker UML

children

File

getSize( )

Resource Tree

Folder

getSize()

getContents()

Node

getSize( )

size =total of sizeof each child

Page 38: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 38

The “Composite” pattern

Use of the pattern in Spelunker, cont. Code examples

public class File extends Node{ private long size = 0;

public long getSize() { return size; }}

public class Folder extends Node{ private Vector contents;

public long getSize() { long size = 0;

if (contents != null) { Enumeration e = contents.elements(); while (e.hasMoreElements()) { size += ((Node)e.nextElement()).getSize(); } } return size; }}

Page 39: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 39

The “Strategy” pattern

Problem The way in which the icons are arranged varies according to user

preference - the user may choose an iconic view only, or a short/long detail view.

Including the algorithms to arrange the icons as methods in ContentsView would make it cumbersome to add new icon arrangement algorithms to ContentsView; ContentsView would have to be subclassed and some implementation details might have to be unnecessarily exposed.

A switch statement would most likely be used to choose the correct arrangement algorithm.

Page 40: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 40

The “Strategy” pattern

How the pattern solves the problem Intent

“Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.” [GHJV94]

Explanation The algorithms for arranging the icons are encapsulated into a

separate interface. The correct arrangement algorithm is chosen polymorphically. ContentsView neither knows nor cares which arrangement is

presently in use.

Page 41: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 41

The “Strategy” pattern

How the pattern solves the problem, cont. Gang of Four UML [GHJV94]

Strategy

AlgorithmInterface()

ConcreteStrategyC

AlgorithmInterface()

ConcreteStrategyB

AlgorithmInterface()

Context

ContextInterface()

strategy

ConcreteStrategyA

AlgorithmInterface()

Page 42: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 42

The “Strategy” pattern

Use of the pattern in Spelunker ContentsView delegates the task of arranging the icons to ViewManager.

Spelunker UML

ViewManager

updateVisibleNodes()

ListViewManager

updateVisibleNodes()

IconViewManager

updateVisibleNodes()

ContentsView

updateVisibleNodes()

strategy

Page 43: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 43

The “Strategy” pattern

Use of the pattern in Spelunker, cont. Code examples

public class ContentsView extends ResourceTreeView{ private ViewManager viewManager;

public void showIconView() { viewManager = new IconViewManager(this); }

public void showListView(boolean showDetail) { viewManager = new ListViewManager(this, showDetail); }

public void updateVisibleNodes(Folder activeFolder) { viewManager.updateVisibleNodes(activeFolder); }}

public interface ViewManager{ public void updateVisibleNodes(Folder activeFolder);}

Page 44: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 44

The “Observer” pattern

Problem What is the best way to keep all views of the file tree in sync?

We need to be able to re-draw the display window after the user modifies a file/folder (e.g., when user clicks on a folder to select it)

However, there may be several windows and panes that display the same file/folder. We need to re-draw all of them.

To do this, the tree needs to keep a list of all of its views, and notify each one after a modification is done.

However, the tree and view objects might: have little other relationship besides this notification need to have their code modified independently need to be reused separately

So it would be preferable not to make them too tightly coupled to each other.

Page 45: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 45

The “Observer” pattern

How the pattern solves the problem Intent

“Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.” [GHJV94]

Explanation The Observer pattern works by defining an abstract class (or

interface) with a single method signature. The method will be used as a mechanism for “observer” objects to be notified of changes in their “subject”.

Concrete observer sub-classes will each provide their own implementation of what to do when the notification occurs.

The subject can notify each observer the same way, without caring which specific sub-class of observer the object actually is.

Page 46: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 46

The “Observer” pattern

How the pattern solves the problem, cont. Gang of Four UML [GHJV94]

subject

observers

Observer

Update( )

Subject

Attach(Observer)Detach(Observer)Notify( )

ConcreteSubjectSubjectState

GetState( )

ConcreteObserverObserverState

Update( )

return SubjectStateObserverState = subject.GetState()

for all o in observers o.update();

Page 47: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 47

The “Observer” pattern

Use of the pattern in Spelunker ResourceTree notifies all ResourceTreeViews whenever its

state is modified. Spelunker UML

ResourceTreeObserver

subject

observers

resourceTreeChanged(Folder)

ResourceTreeactiveFolder

AttachObserver(ResourceTreeObserver)DetachObserver(ResourceTreeObserver)NotifyObservers( )

ResourceTreeView

updateVisibleNodes(activeFolder);repaint();Enumeration e = observers.elements();

while (e.hasMoreElements()) { ResourceTreeObserver o = (ResourceTreeObserver)e.nextElement(); o.resourceTreeChanged(activeFolder);}

resourceTreeChanged( Folder activeFolder)

Page 48: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 48

The “Observer” pattern

Use of the pattern in Spelunker, cont. Code examples

public class ResourceTree { private Vector observers;

public void setActiveFolder(Folder folder) { if (activeFolder != folder) { activeFolder = folder; notifyObservers(); } }

public void notifyObservers() { Enumeration e = observers.elements(); while (e.hasMoreElements()) { ((ResourceTreeObserver)e.nextElement()).resourceTreeChanged(activeFolder); } }}

public abstract class ResourceTreeView extends Panel implements ResourceTreeObserver {

public void resourceTreeChanged(Folder activeFolder) { updateVisibleNodes(activeFolder); repaint(); }}

Page 49: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 49

The “Proxy” pattern

Problem Network drives might require the user to login before the drive can

be accessed - however, the protocol for accessing a network drive when logged in might not differ from accessing a local drive.

LocalDrive should not contain network code - this code should be moved to a separate class, i.e. NetworkDrive.

Creating NetworkDrive as a subclass of LocalDrive would be complicated and unwieldy - we would have to check access everytime a drive operation was requested.

Creating NetworkDrive as a subclass of Folder would force us to duplicate all drive access operations already in LocalDrive.

Page 50: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 50

The “Proxy” pattern

How the pattern solves the problem Intent

“Provide a surrogate or placeholder for another object to control access to it.” [GHJV94]

“A Protection Proxy controls access to the original object. Protection Proxies are useful when objects should have different access rights.” [GHJV94]

Explanation The network protocols necessary for logging in and out are

moved into a subclass of Folder called NetworkDrive. NetworkDrive contains the code necessary for logging in and out

of a network drive. After logging in, NetworkDrive delegates drive access requests to

LocalDrive (indirectly through ConnectionState).

Page 51: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 51

The “Proxy” pattern

How the pattern solves the problem, cont. Gang of Four UML [GHJV94]

Subject

Request()

Proxy

Request()

RealSubject

Request()

realSubject

...RealSubject->Request();...

Page 52: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 52

The “Proxy” pattern

Use of the pattern in Spelunker NetworkDrive acts as a Proxy for a remote LocalDrive. Spelunker UML

Note:NetworkDrive delegates to LocalDrive indirectly through ConnectionOpenedState.

Folder

getContents()

NetworkDrive

getContents()

LocalDrive

getContents()

realSubject

...localDrive.getContents();...

Page 53: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 53

The “Proxy” pattern

Use of the pattern in Spelunker, cont. Code examples

public class NetworkDrive extends Folder{ private ConnectionState connectionState;

public Vector getContents(Folder folder) { return connectionState.getContents(folder); }}

public class ConnectionOpenedState extends Object implements ConnectionState{ private LocalDrive localDrive;

public Vector getContents(Folder folder) { return localDrive.getContents(folder); }}

Page 54: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 54

The “State” pattern

Problem What is the best way to perform password-protection processing

on network drives? Network drives need to act differently depending on whether the user

has logged in or not; e.g., the user cannot examine or modify a network drive until they log in.

This can be accomplished by checking a condition before executing each operation; e.g., “if (loggedIn())”. But this is ugly code, as well as being inefficient and repetitive.

This is also difficult to extend: what if we need to implement another set of checks for another condition; e.g., “if (!disconnected())”?

The design would be less complex and more flexible if we could isolate in one location all behavior related to a particular state of the object.

Page 55: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 55

The “State” pattern

How the pattern solves the problem Intent

“Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.” [GHJV94]

Explanation The State pattern works by creating an abstract class (or interface) with method

signatures for every state-dependent operation in the main object, and concrete sub-classes that provide implementations for these methods. The main object then delegates each of these operations to the state object it is currently using.

Each state class can implement each operation in its own way (e.g., perform unique processing, disallow the operation, throw an exception, etc.).

The main object can change its behavior by changing the state object it is using. This is a very clean design - and also extendible: we can simply add new state

classes to add additional behavior, without modifying the original object.

Page 56: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 56

The “State” pattern

How the pattern solves the problem, cont. Gang of Four UML [GHJV94]

state

Context

Request( )

ConcreteStateB

HandleRequest( )

State

HandleRequest( )

ConcreteStateA

HandleRequest( )

state.HandleRequest()

Page 57: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 57

The “State” pattern

Use of the pattern in Spelunker The NetworkDrive delegates operations to its

ConnectionState. Spelunker UML

state

NetworkDrive

getContents()

ConnectionClosedState

getContents( )

ConnectionState

getContents( )

ConnectionOpenedState

getContents( )

return connectionState.getContents()

changeState(ConnectionState)

Page 58: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 58

The “State” pattern

Use of the pattern in Spelunker, cont. Code examples

public class ConnectionClosedState implements ConnectionState {

public void login() { LocalDrive localDrive = null;

// login and initiate localDrive

networkDrive.changeState(new ConnectionOpenedState(networkDrive, localDrive)); }

public Vector getContents(Folder folder) { login(); return networkDrive.getContents(folder); }}

public class ConnectionOpenedState implements ConnectionState { public void login() { // display error }

public Vector getContents(Folder folder) { return localDrive.getContents(folder); }}

Page 59: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 59

The “Command” pattern

Problem A request might need access to any number of classes. The initiator of the request should not be tightly coupled to

these classes. Requests should be storable to support undoable

operations; therefore, requests must be accessible through some common interface.

How do we implement requests without coupling them to the initiator or target, or requiring the initiator to know the implementation details of the request ?

Implementing the code for all requests in one class would centralize the application and make it difficult to create new requests.

Page 60: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 60

The “Command” pattern

How the pattern solves the problem Intent

“Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.” [GHJV94]

Explanation Places the implementation of a request into a separate class. Initiators of the request do not know any implementation details of the

request - they simply fire it off by calling the execute() method. The targets of the request do not need to know anything about the

request. All requests are accessible through a common interface. The correct implementation is chosen polymorphically.

Page 61: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 61

The “Command” pattern

How the pattern solves the problem, cont. Gang of Four UML [GHJV94]

Command

Execute()

ConcreteCommand

Execute()

Receiver

Action()receiver

Client Invoker

receiver->Action();

state

Page 62: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 62

The “Command” pattern

Use of the pattern in Spelunker Used to implement user operations on files and folders. Spelunker UML

Command

execute()

DeleteCommand

execute()

ContentsView

getSelectedNodes()receiver

SkylightSpelunker

CommandButton

...Vector selectedNodes = contentsView.getSelectedNodes();...if (!node.deleteNode(node)) {...

Page 63: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT 63

The “Command” pattern

Use of the pattern in Spelunker, cont. Code examples

public class CommandButton extends Button { private Command command;

public CommandButton(String label, Command command) { super(label); this.command = command; }

public boolean action(Event e, Object what) { command.execute(); return super.action(e, what); }}

public class DeleteCommand extends Command { private ContentsView contentsView; private ResourceTree resourceTree;

public void execute() { (code for retrieving all selected Nodes

from ContentsView and deleting them) }}

public abstract class Command extends Object { public abstract void execute();}

Page 64: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Basis Litteratur (Pattern kataloger)Basis Litteratur (Pattern kataloger)

Design Patterns, Elements of Reusable Object-Oriented SoftwareGamma et. al. Addison-Wesley, ISBN 0-201-63361-2

Analysis Patterns, Reusable Object ModelsMartin Fowler, Addison-Weslwy, ISBN 0-201-89542-0

Pattern-Oriented Software ArchitectureF. Buschmann et. al, J. Wiley, ISBN 0-471-95869-7

http://st-www.cs.uiuc.edu/users/patterns/patterns.html

http://c2.com/ppr/index.html

AntiPatterns - Refactoring Software, Architectures, and Projects in CrisisW. Brown et. al, J. Wiley, ISBN 0-471-19713-0

Page 65: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Tilleggs litteraturTilleggs litteratur

Design Patterns for Object-Oriented Software Development,Pree, Addison-Wesley, ISBN 0-201-42294-8, 1995

CORBA Design Patterns, T. Mowbray, R. Malveau, j. Wiley, 1997, ISBN 0-471-15882-8

Communications of ACM, “Software Patterns” - special issueOctober 1996, Vol. 39, Number 10

Pattern Languages of Program Design 1J. Coplien, Douglas SchmidtAddison-Wesley, ISBN 0-201-60734-4, 1995

Pattern Languages of Program Design 2J. Vlissides, J. Coplien, N. KerthAddison-Wesley, ISBN 0-201-89527-7, 1996

Page 66: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Refactoring - Improving the design of existing code

1. Refactoring - a first example 2. Principles in refactoring 3. Bad Smells in Code 4. Building Tests 5. Toward a catolog of refactorings 6. Composing Methods 7. Moving Features between objects 8. Organizing data 9. Simplifying Conditional Expressions 10. Making Method calls simpler 11. Dealing with Generalization 12. Big Refactorings 13. Refactoring, Reuse and Reality 14. Refactoring tools

M. Fowler, with K. Beck, J. Brant, W. Opdyke, D. Roberts, Addison-Wesley, August 1999

Refactoring: Improving the design of existing code

Page 67: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Refactoring - What and Why ?

Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves its internal structure.

Improving to make it easier to understand and cheaper to modify

Page 68: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

When should you refactor

The rule of three - Three strikes and you refactor Refactor when you add function Refactor when you need to fix a bug Refactor as you do a code review

Page 69: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Why refactoring works

Programs that are hard to read are hard to modify Programs that have duplicated logic are hard to modify Program that require additional behaviour that requries you

to change running code are hard to modify Programs with complex conditional logic are hard to modify

We want programs that are easy to read, that have all logic specified in one and only one place, do not allow changes to endanger existing behaviour, and allow conditional logic to be expressed as simply as possible

Page 70: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Refactoring strategies

Composing Methods Moving features between objects Organizing data Simplifying conditional expressions Making method calls simpler Dealing with generalization Big refactorings

Page 71: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Composing Methods

Extract method Inline method Inline temp Replace temp with query Introduce explaining variable Split temporary variable Remove assignments to parameters Replace method with method object Substitute algorithm

Page 72: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Moving Features between objects

Move method Move field Extract Class Inline Class Hide Delegate Remove middle man Introduce foreign method Introduce local extension

Page 73: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Bad Smells in Code (1/4)

Duplicated Code (extract method, extract class, pull up method, form template method)

Long Method (extract method, replace temp with query, replace method with method object, decompose conditional)

Large Class (extract class, extract subclass, extract interface, replace data value with object)

Long ParameterList (replace parameter with method, introduce parameter object, preserve whole object)

Divergent Change (extract class)

Page 74: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Bad Smells in Code (2/4)

Shotgun Surgery (move method, move field, inline class) Feature Envy (move method, move field, extract field) Data Clumps (extract class, introduce parameter object,

preserve whole object) Primitive Obsession (replace data value with object, extract

class, introduce parameter object, replace array with object, replace type code with class/subclasses, replace type code with state/strategy)

Switch Statements (replace conditional with polymorphism, replace type code with subclasses/state/strategy, replace parameter with explicit methods, introduce null object)

Page 75: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Bad Smells in Code (3/4)

Parallell Inheritance Hierarchies (move method, move field)

Lazy Class (inline class, collapse hierarchy) Speculative Generality (collapse hierarchy, inline class,

remove parameter, rename method) Temporary Field (extend class, introduce null object) Message Chains (hide delegate) Middle Man (remove middle man, inline method,

replace delegation with inheritance) Inappropriate Intimacy (move method, move field,

change bidirection to unidirectional)

Page 76: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Bad Smells in Code (4/4)

Alternative classes with different interfaces (rename method, move method)

Incomplete Library Class (introduce foreign method, introduce local extension)

Data Class (move method, encapsulate field, encapsulate collection)

Refused Bequest (replace inheritance with delegation)

Comments (extract method, introduce assertion)

Page 77: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Organizing data Self encapsulate field Replace data value with object Change value to reference Change reference to value Replace array with object Duplicate observed data Change unidirectional association to bidirectional Change bidirectional association to unidirectional Replace magic number with symbolic constant Encapsulate field Encapsulate collection Replace record with data class Replace type code with class/sublasses Replace type code with state/strategy Replace subclass with fields

Page 78: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Simplifying Conditional Expressions

Decompose conditional Consolidate conditional expression Consolidate duplicate conditional fragments Remove control flag Replace nested conditional with guard clauses Replace conditional with polymorphism Introduce null object Introduce assertion

Page 79: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Making Method calls simpler Rename method Add parameter Remove parameter Separate query from modifier Parameterize method Replace parameter with explicit methods Preserve whole object Replace parameter with method Introduce parameter object Remove setting method Hide method Replace constructor with factory method Encapsulate downcast Replace error code with exception Replace exception with test

Page 80: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Dealing with Generalization

Pull up field Pull up method Pull up constructor body Push down method Push down field Extract subclass Extract superclass Extract interface Collapse hierarchy Form template method Replace inheritance with delegation Replace delegation with inheritance

Page 81: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Big refactorings

Tease apart inheritance Convert procedural design to objects Separate domain from presentation Extract hierarchy

Page 82: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

The rhythm of refactoring ...

test, small change, test, small change, test, ….

… allows refactoring to move quickly and safely

Page 83: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

AntiPatterns

Refactoring Software, Architectures , and Projects in Crisis: W. Brown, R. Malveau. H. McCormick, T. Mowbray, Wiley, 1998

AntiPattern: A commonly occuring patterns or solution that generates decidely negative consequences. An AntiPatterns may be a pattern in the wrong context. When properly documented, an AntiPattern comprises a paired AntiPattern solution with a refactored solution.

Page 84: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Software Development AntiPatterns

The Blob (from the film) Continuous Obsolescence Lava Flow Ambiguous Viewpoint Functional Decomposition Poltergeists Boat Anchor Golden Hammer Dead End Spaghetti Code Input Kludge Walking through a Minefield Cut-and-Paste Programming Mushrooom management

Page 85: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Software Architecture AntiPatterns

Autogenerated Sovepipe Stovepipe Enterprise Jumble Stovepipe System Cover your Assets Vendor Lock-In Wolf Ticket Architecture by Implication Warm bodies Design by Committee Swiss Army Knife Reinvent the Wheel The Grand Old Duke of York

Page 86: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Software Project Management AntiPatterns

Blowhard Jamboree Analysis Paralysis Viewgraph Engineering Death by Planning Fear of Success Corncob Intellectual Violence Irrational Management Smoke and Mirrors Project Mismanagement Throw it over the wall Fire Drill The Feud E-mail is dangerous

Page 87: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Practical Refactoring exercise

Page 88: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Example:Video rental Bad smells: Long Method Feature Envy Switch statements Temporary Fields Support change ?: Add HTML

statement, change classification of films

Customer1

+ statement()

Rental1

daysRented : int

0..* 10..* 1

Movie1

priceCode : int1 0..*1 0..*

Page 89: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

extract from statement()

public String statement() {

/ ….. Determine amounts for each rental Switch (each.getMovie().getPriceCode()) { case Movie.REGULAR thisAmount += 2; …..

// add frequent renter pointsfrequentRenterPoints ++;

if (each.getMovie().getPriceCode() -----

// show figures for this rental

// add footer lines

}

Page 90: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Refactorings:Video rental

Create Tests to check refactoring correctness Decomposing and redistributing the statement

method (extract method, moving the amount calculation amountFor() (move the method from customer to rental), rename variables (I.e each -> aRental)

similar: extracting frequent renter points, removing temps (totals) replaceTempWithQuery totalAmount/freqRentPoint,

Page 91: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Extracting and Moving methods

Customer1

+ statement()

Rental1

daysRented : int

getCharge()getFreqRentPoints()

0..* 10..* 1

Movie1

priceCode : int1 0..*1 0..*

Customer1

+ statement()+ getTotalCharge()+ getTotFreqRentPoints()

Rental1

daysRented : int

getCharge()getFreqRentPoints()

0..* 10..* 1

Movie1

priceCode : int1 0..*1 0..*

Page 92: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Move calculation of charge and pointsto the “expert”

Customer1

+ statement()+ getTotalCharge()+ getTotFreqRentPoints()

Rental1

daysRented : int

getCharge()getFreqRentPoints()

0..* 10..* 1

Movie1

priceCode : int

getCharge(days : int)getFreqRentPoints(days : int)

10..*10..*

Page 93: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Refactorings:Video rental

replace conditional logic on price code with polymorphism, using inheritance - problem: a movie can change its classification during its lifetime -> use the state pattern for price code object (or strategy) -> replace type code with state/strategy, move method (switch into price class), replace conditional with polymorphism to eliminate switch

Page 94: ICT INF5120 – Modellbasert Systemutvikling F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 Arne-Jørgen Berre

ICT

Customer1

+ statement()+ getTotalCharge()+ getTotFreqRentPoints()+ htmlstatement()

Rental1

daysRented : int

getCharge()getFreqRentPoints()

0..* 10..* 1

ChildrensPrice

getCharge(days : int)

NewReleasePrice

getCharge(days : int)getFreqRentPoints(days : int)

RegularPrice

getCharge(days : int)

Movie1

priceCode : int

getCharge(days : int)getFreqRentPoints(days : int)

1

0..*

1

0..*

Price

getCharge(days : int)getFreqRentPoints(days : int)

11