Software Refactoring Part I: Introduction

Advanced Object-Oriented Design Lecture 5 Software RefactoringPart I: Introduction Bartosz Walter <Bartek.Walter@man.poznan.pl>

Motto „Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” Martin Fowler

Agenda Refactoring: ideas, motivation, examples Verification of refactorings Bad smells in code

More functionality!

Oh, I've found a bug...

We've got no time. Let's integrate...

Motivation for refactoring • High cost of maintenance • Yourdon: 80% of TCD • Software decays during development • Low understanding of code • Design does not fit the requirements/ functionality • YAGNI = You Aren't Going to Need It

Refactoring Refactoring is: • a change made to the internal structure of software • to make it easier to understand and cheaper to modify • without changing its observable behaviour void doSth() void doSth() Source: W. Opdyke

void compute () { // compute X // compute Y print(X, Y); // store X // store Y } void compAndPrint() { // compute X // compute Y ... // print X // print Y ... // store X // store Y } void print(X,Y) { // print X // print Y } Simplest example Extract Method • One method – one function • Allows localizing the potential bugs

void compute () { X = next(X); Y = next(Y); } void compAndPrint() { ... X++; Y++; ... } int next(N) { return N++; } Simplest example (reverted) Inline Method • Removal of very short methods

Cost of refactoring Refactoring is costly because it does not add new functions to the system. The cost depends on: • the language used • support from CASE tools • the type of refactorings • number and quality of test cases Important factors: • cost of documentation update • cost of test cases update

Unfinished refactoring is like going into debt. You can live with it, but it is costly. Ward Cunningham When to do and not do refactoring? • At close deadlines • Prematurely published interfaces • Unstable, rubbish code • Three strikes and refactor • When adding new functions • When fixing a bug • While inspecting code

Verification of refactorings SIMPLE HARD • Automated verification • Implemented in many IDEs • Verification requires testing • Tests need to be manually created

Simple refactorings... • Verification of pre-conditions • Static analysis of code void doSth() void doSth() If before....If before.... Then after....Then after....

void doSth() void doSth() If before....If before.... Then after....Then after.... ... and hard ones • Static code analysis, preconditions • Role of unit tests

Bad smells If it stinks, change it Kent Beck grandmadiscussing child-rearing philosophy

Duplicated Code Same or similar code appears all over the system • in same class: extract out the common bits into their own method (extract method) • in sibling classes: extract method with a shared functionality and then pull up the method to a common superclass • in unrelated classes: extract class

Long Method Same or similar code appears all over the system • Too many options, causing the method to do too many things • Not enough support from other methods, causing the method to do tasks at a lower level than it should • Overly complicated exception handling • the rule of one screen/twenty lines • extract code

Large class Same or similar code appears all over the system • No clear definition of what the class should do, resulting in it doing rather a lot of different things • Out-of-control inner classes • Numerous static and instance methods • Excessive numbers of convenience methods • Cut-and-pasted code • extract new class/subclass/interface • pull up methods/fields

Long Parameter List Method needs to much external information • replace parameter with method (receiver explicitly asks sender for data via sender getter method) • replace parameters with a member fields in a dedicated object

Divergent Change Same or related code appears all over the system Many different changes are necessary • Separate out the varying code into varying classes (extract class) that either subclass or are contained by the non-varying class • Use Visitor or Self Delegation patterns

Feature Envy Method in one class uses lots of pieces from another class • move method to the other class • use Visitor or Self Delegation patterns

Data Clumps Data that's always hanging with each other (e.g. name street zip) • Extract out a class (extract class) for the data • Related to long parameter list. • Introduce a Parameter Object • Preserve whole object

Summary Finally! • Refactoring decreases cost of maintenance • Refactoring preserves software behaviour • Testing and analysis as methods of verification • Code smells indicate a need for refactoring

Q&A ?

Software Refactoring Part I: Introduction