Principles and examples Refactoring Principles and examples

The goals of a module Functionality The reason for the module's existance Changeability Most modules change during their lifetime If it is hard to change, it is broken and should be fixed Communicatability Modules are read by developers If a developer cannot understand what is happening without serious analysis and pondering, the module is broken and should be fixed

Definitions of refactoring Altering the internal structure without affecting the external behavior Robert C. Martin A change made to the internal structure of sofware to make it easier to understand and chepaer to modify without changing its observable behavior Martin Fowler To restructure software by applying a series of refactorings without changing its observable form

Why refactor? Refactoring improves the design of software Designs decay over changes Code loses its structure Negative spiral Reducing the amount of code Less code is always better Refactoring makes software easier to understand Other people can easier understand well-structured code You, yourself can easier understand well-structured code Refactoring helps you find bugs Understanding code makes it easier to see problems and errors “I'm not a great programmer, I'm just a good programmer with great habits” Kent Beck Refactoring helps you program faster Good design makes it easier to develop faster

When refactor? Refactor when you add function Refactor first Add new functionality then (in a “green” mode)‏ Refactor when you fix a bug Obviously the code wasn't good enough to see the bug in the first place Refactor when doing code reviews It might be clear to you, but not to others Pair programming is code review

Bad smells in code Duplicated code Long method Large class Long parameter list Divergent change Shotgun surgery Feature envy Data clumps Primitive obsession Switch statements Parallel inheritance structures Lazy class Speculative generality Temporary field Message chains Middle man Inappropriate intimacy Alternative classes with different interfaces Incomplete library class Data class Refused bequest Comments

Bad smells and how to sniff them out Duplicated code Same code more than once Long method Too many LOC Large class Too many instance variables Long parameter list Usually bad in an OO environment Divergent change Many changes affect same class Shotgun surgery One change alters many classes Feature envy A method often accesses another class's data Data clumps Data that always is used in clumps shuold be together Primitive obsession Too much use of built-in types Switch statements In OO, inheritance is preferred Parallel inheritance structures ??

Bad smells and how to sniff them out (cont'd)‏ Lazy class Classes that don't do much Speculative generality Hooks for possible future additions Temporary field Instance variables that are only used occasionally Message chains t.get().get().get().get()‏ Middle man Delegating to much Inappropriate intimacy Classes peek and poke at private parts Alternative classes with different interfaces Methods do the same, but have different names Incomplete library class You only use parts of a library Data class Data + get + set only Refused bequest Subclasses only uses parts of what is inherited Comments Might be there because the code is impossible to understand without them

Refactorings Patterns for refactoring code Name Summary Motivation Mechanics Examples

Composing methods Extract method Block of code --> method Inline method Method --> block of code Inline temp Remove temp variable Replace temp with query method Removing temp variables, making their computation a method Replace method with method object Complicated method --> object with several methods Introduce explaining variable Complex expressions are easier to understand with some variables with good names Split temporary variable Don't use same variable for different semantics

Composing methods (cont'd)‏ Remove assignments to parameters Instead of changing a parameters value, copy it and change Substitute algorithm Bad algorithm --> good algorithm

Moving features between objects Move methods a.method() --> b.method()‏ Move field a.aField --> b.aField Extract class One class with two responsibilities --> two classes with one resp. each Inline class Two classes with one resp. each --> One class with two responsibilities Hide delegate a.getB().getC() --> a.getC()‏ Remove middle man a.getC() --> a.getB.getC()‏

Organizing data Self encapsluate field Getters for private data in own class Replace data with object Dumb data --> articluate object Change value to reference Factory method Change reference to value opposite Replace array with object a[0]=”name”, a[1]=”address” --> o.name(“name”), o.address(“address”)‏ Replace magic number with symbolic constant 9.81 --> Gravitation =9.81 Encapsulate field public int x --> private int x, getx, setx

Making method calls simpler Rename method Unreadable --> readable Add parameter method() --> method(param)‏ Remove parameter method(param) --> method() Separate query from modifier Procedure vs function Parametereize method multiplyByTen, multiplyByFive --> multiply(factor)‏ Preserve whole object f(o.getX()), g(o.getY()) --> fg(o)‏

Making method calls simpler (cont'd)‏ Introduce parameter object printdate(year, month, day) --> printdate(dateobject)‏ Replace parameter with method o.doStuff(thing, getSomething()) --> o.doStuff(thing)‏ Replace parameter with explicit methods setvalue(whatToSet, value) --> setvalue1, setvalue2 Remove setting method o.initializeX() --> done in constructor Hide method Make methods not used by others private Encapsulate downcast a = (realType) b.getStuff() --> a = b.getrealStuff()‏ Replace exception with test Test before is better than test after

Dealing with generalization Pull up field Subclasses have same field --> superclass has it instead Pull up method dito Push down field Some subclasses uses a field i superclass --> put them there Push down method Dito Extract superclass Two classes have something in common --> put in superclass and subclass both from it Extract interface Parts of classes common --> make it an interface Collapse hierarchy Subclass and superclass are similar --> make them one

Dealing with generalization Replace inheritance with delegation Only parts of superclass is used --> delegate instead Replace delegation with inheritance To many delegation methods to same object --> super/subclass