EMOOSE Object-Oriented Software Evolution Dr. Tom Mens Programming Technology Lab Vrije Universiteit Brussel Pleinlaan Brussel Belgium Refactoring Basics

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 2 Bibliography - Books  K. Beck. Smalltalk best practice patterns. Prentice Hall,  M. Fowler. Refactoring: improving the design of existing programs. Addison-Wesley, 1999.

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 3 Bibliography – PHD Theses  W. G. Griswold. Program restructuring as an aid to software maintenance. University of Washington, USA, August  W. F. Opdyke. Refactoring object-oriented frameworks. University of Illinois at Urbana-Champaign, USA,  I. Moore. Automatic restructuring of object-oriented programs. Manchester University, UK,  S. Tichelaar. Modeling object-oriented software for reverse engineering and refactoring. PhD Thesis, University of Bern, Switzerland, 2001.

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 4 Bibliography - Articles  P. L. Bergstein. “Maintenance of Object-Oriented Systems During Structural Evolution,” TAPOS Journal 3(3): , 1997  S. Demeyer, S. Ducasse, O. Nierstrasz. Finding refactorings via change metrics. Proc. OOPSLA 2000, ACM Press,  B. Foote, W. F. Opdyke. Life cycle and refactoring patterns that support evolution and reuse,  W. G. Griswold, D. Notkin. Automated assistance for program restructuring. ACM Trans. Software Engineering and Methodology, 2(3): , July  R. E. Johnson, W. F. Opdyke. Refactoring and aggregation,  I. Moore. Automatic inheritance hierarchy restructuring and method refactoring, Proc. Int. Conf. OOPSLA 1996.

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 5 Bibliography – Articles ctd.  W. F. Opdyke, R. E. Johnson. Creating abstract superclasses by refactoring. Proc. ACM Computer Science Conf., pp , ACM Press,  D. Roberts, J. Brant, R. E. Johnson. A refactoring tool for Smalltalk. TAPOS Journal 3(4): ,  S. Tichelaar, S. Ducasse, S. Demeyer, O. Nierstrasz. A Meta-Model for Language-Independent Refactoring,  L. Tokuda, D. Batory. Automated Software Evolution via Design Pattern Transformations. Proc. 3rd Int. Symp. Applied Corporate Computing, October  L. Tokuda, D. Batory. Automating Three Modes of Evolution for Object-Oriented Software Architectures. In 5 th Conference on Object-Oriented Technologies, 1999.

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 6 Basic Issues in refactoring  What is refactoring?  Why should you refactor?  When should you refactor?  Categories of refactorings

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 7 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

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 8 What is refactoring?  A refactoring is a software transformation that  preserves 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

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 9 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  …

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 10 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

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 11 When should you refactor?  Only if you see the need for it  Not on a preset periodical basis  Apply the rule of three  1 st time: implement from scratch  2 nd time: implement something similar by code duplication  3 rd 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

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 12 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])

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 13 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

EMOOSE, January 2002© Tom Mens, Programming Technology Lab Creating template methods A m { … … } B C D A m { … this.n … } n { } B C n { ;super.n } D separate common behaviour (m) from specialised parts (n)

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 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

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 16 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

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 17 2.a Refactor to Specialise Disk Management for DOS Disk disktype... copyDisk formatDisk Disk Management for DOS &MAC formatDisk self diskType = #MSDOS ifTrue: [.. code1..]. self diskType = #MAC ifTrue: [.. code2..]. Disk Management for DOS & MAC Disk... copyDisk formatDisk... DOSDisk... copyDisk formatDisk... MACDisk... copyDisk formatDisk... Disk... copyDisk formatDisk...

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 18 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

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 19 2.b Refactor to generalise concrete class A concrete class B abstraction concrete class Aconcrete class B abstract class X

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 20 2.b Refactor to generalise  Steps to create an abstract superclass  Create a common superclass  Make method signatures compatible  Add method signatures to the superclass  Make method bodies compatible  Make instance variables compatible  Move instance variables to the superclass  Move common code to the abstract superclass

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 21 2.b Refactor to generalise  Example PrintServer print:Boolean FileServer save FileServerPrintServer OutputServer output

EMOOSE, January 2002© Tom Mens, Programming Technology Lab 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]

EMOOSE, January 2002© Tom Mens, Programming Technology Lab Incorporating composition relationships  Example  Convert inheritance into aggregation rep Matrix 2DArray SparseMatrix2DArray MatrixRepresentation output Matrix