EMOOSE 2001-2002 Object-Oriented Software Evolution Dr. Tom Mens [email protected] Programming Technology Lab Vrije Universiteit

EMOOSE 2001-2002Object-Oriented Software Evolution

Dr. Tom [email protected]

Programming Technology Lab

http://prog.vub.ac.be

Vrije Universiteit Brussel

Pleinlaan 2 - 1050 Brussel

Belgium

Refactoring Basics

mailto:[email protected]

http://prog.vub.ac.be/

2EMOOSE, January 2002 © Tom Mens, Programming Technology Lab

Bibliography - Books

K. Beck. Smalltalk best practice patterns. Prentice Hall, 1997.

M. Fowler. Refactoring: improving the design of existing programs. Addison-Wesley, 1999.


Bibliography – PHD Theses

W. G. Griswold. Program restructuring as an aid to software maintenance. University of Washington, USA, August 1991.

W. F. Opdyke. Refactoring object-oriented frameworks. University of Illinois at Urbana-Champaign, USA, 1992.

I. Moore. Automatic restructuring of object-oriented programs. Manchester University, UK, 1996.

S. Tichelaar. Modeling object-oriented software for reverse engineering and refactoring. PhD Thesis, University of Bern, Switzerland, 2001.


Bibliography - Articles

P. L. Bergstein. “Maintenance of Object-Oriented Systems During Structural Evolution,” TAPOS Journal 3(3): 185-212, 1997

S. Demeyer, S. Ducasse, O. Nierstrasz. Finding refactorings via change metrics. Proc. OOPSLA 2000, ACM Press, 2000.

B. Foote, W. F. Opdyke. Life cycle and refactoring patterns that support evolution and reuse, 1995.

W. G. Griswold, D. Notkin. Automated assistance for program restructuring. ACM Trans. Software Engineering and Methodology, 2(3): 228-269, July 1993.

R. E. Johnson, W. F. Opdyke. Refactoring and aggregation, 1993. I. Moore. Automatic inheritance hierarchy restructuring and method

refactoring, Proc. Int. Conf. OOPSLA 1996.


Bibliography – Articles ctd.

W. F. Opdyke, R. E. Johnson. Creating abstract superclasses by refactoring. Proc. ACM Computer Science Conf., pp. 66-73, ACM Press, 1993.

D. Roberts, J. Brant, R. E. Johnson. A refactoring tool for Smalltalk. TAPOS Journal 3(4): 253-263, 1997.

S. Tichelaar, S. Ducasse, S. Demeyer, O. Nierstrasz. A Meta-Model for Language-Independent Refactoring, 2000.

L. Tokuda, D. Batory. Automated Software Evolution via Design Pattern Transformations. Proc. 3rd Int. Symp. Applied Corporate Computing, October 1995.

L. Tokuda, D. Batory. Automating Three Modes of Evolution for Object-Oriented Software Architectures. In 5th Conference on Object-Oriented Technologies, 1999.


Basic Issues in refactoring

What is refactoring? Why should you refactor? When should you refactor? Categories of refactorings


What is refactoring?

Life-cycle of object-oriented software development Three phases [Foote&Opdyke1995]

prototyping initial development using rapid prototyping and incremental

changes

expansion add new user requirements in the form of classes, operations

consolidation Reorganise the software to make it more reusable/manageable Introduce frameworks and design patterns / use refactoring


What is refactoring?

A refactoring is a software transformation thatpreserves the external behaviour of the software improves the internal structure of the software

Refactoring [Fowler 1999] [noun] a change made to the internal structure of

software to make it easier to understand and cheaper to modify without changing its observable behaviour

[verb] to restructure software by applying a series of refactorings without changing its observable behaviour


Why should you refactor?

To improve the software design To counter code decay (software aging) To increase software understandibility To increase productivity (program faster)

on a long term basis, not on a short term basis

To reduce costs of software maintenance …


Why should you refactor?

… To find bugs and write more robust code To reduce testing

automatic refactorings are guaranteed to be behaviour-preserving

To prepare for / facilitate future customisations To turn an OO application into a framework

introduce design patterns in a behaviourally preserving way


When should you refactor?

Only if you see the need for it Not on a preset periodical basis

Apply the rule of three 1st time: implement from scratch 2nd time: implement something similar by code duplication 3rd time: do not implement similar things again, but refactor

Refactor when adding new features Especially if feature is difficult to integrate with the existing code

Refactor during bug fixing If a bug is very hard to trace, refactor first to make the code

more understandable Refactor during code reviews


Categories of refactorings

Based on granularity low-level (primitive) vs high-level (composite) refactorings

Based on programming language language-specific (e.g. Java, Smalltalk, ...) language-independent (e.g. [Tichelaar&al 2000])

Degree of formality formal (e.g. [Bergstein 1997]) ad-hoc (e.g. [Fowler 1999]) semi-formal

Degree of automation fully automated (e.g. [Moore 1996]) interactive (e.g. Refactoring Browser of [Roberts&al 1997]) fully manual (e.g. [Fowler 1999])


Categories of refactorings

Three categories corresponding to generic design evolutions occuring frequently in OO software systems (according to [Demeyer&al 2000])1. Create template methods

split methods into smaller chunks to separate common behaviour from specialised parts so that subclasses can override

used to improve reusability, remove duplicated functionality

2. Optimise class hierarchies insert or remove classes within a class hierarchy and redistribute

the functionality accordingly used to increase cohesion, simplify interfaces, remove duplicated

functionality

3. Incorporate composition relationships move functionality to (newly created) sibling classes used to reduce coupling, migrate towards black-box frameworks


1. Creating template methods

A

m { … … }

B

m { … … }

C

m { … … }

D

A

m { … this.n … }n { }

B

n { }

C

n { ;super.n }

D

separate common behaviour (m)from specialised parts (n)


2. Optimising class hierarchies

a) Refactor to specialise improve framework design by decomposing a large,

complex class into several smaller classes the complex class usually embodies both a general

abstraction and several different concrete cases that are candidates for specialisation

b) Refactor to generalise identify proper abstractions (e.g. abstract classes)

by examining concrete examples and generalising their commonalities


2.a Refactor to Specialise

Specialise a class by adding subclasses corresponding to the conditions in a conditional expression: choose a conditional whose conditions suggest subclasses (this

depends on the desired abstraction) for each condition, create a subclass with a class invariant that

matches the condition copy the body of the condition to each subclass, and in each

class simplify the conditional based on the invariant that is true for the subclass

specialise some (or all) expressions that create instances of the superclass


2.a Refactor to Specialise

Disk Management for DOS

Diskdisktype...copyDiskformatDisk

Disk Management for DOS &MAC

formatDisk self diskType = #MSDOS ifTrue: [ .. code1 ..]. self diskType = #MAC ifTrue: [ .. code2 ..].

Disk Management for DOS & MAC

Disk...

copyDiskformatDisk

...

DOSDisk...

copyDiskformatDisk

...

MACDisk...

copyDiskformatDisk

...

Disk...

copyDiskformatDisk

...


2.b Refactor to generalise

Abstract classes and frameworks are generalisations People think concretely, not abstractly Abstractions are found bottom up, by examining

concrete examples first Generalisation proceeds by:

finding things that are given different names but are really the same (and thus renaming them)

parameterising to eliminate differences breaking large things into small things so that similar

components can be found



concrete class A

concrete class B

abstraction

concrete class A concrete class B

abstract class X



Steps to create an abstract superclassCreate a common superclassMake method signatures compatibleAdd method signatures to the superclassMake method bodies compatibleMake instance variables compatibleMove instance variables to the superclassMove common code to the abstract superclass



Example

PrintServer

print:Boolean

FileServer

save

FileServerPrintServer

OutputServer

output


3. Incorporating composition relationships

Motivation Inheritance is sometimes overused and incorrectly used in

modelling the relationships among classes Aggregations are another way to model these relationships

Refactorings regarding aggregations move instance variables/methods from an aggregate class to

the class of one of its components move instance variables/methods from a component class to

the aggregate classes that contain components which are instances of the component class

convert a relationship, modelled using inheritance, into an aggregation and vice versa [Johnson&Opdyke1993]


3. Incorporating composition relationships

ExampleConvert inheritance into aggregation

rep

Matrix

2DArray

SparseMatrix2DArray

MatrixRepresentation

output

Matrix

Documents

EMOOSE 2001-2002 Object-Oriented Software Evolution Dr. Tom Mens [email protected] Programming Technology Lab Vrije Universiteit