refactoring overview what is refactoring? what are four good reasons to refactor? when should you...

26
Refactoring Overview What is refactoring? What are four good reasons to refactor? When should you refactor? What is a bad smell (relative to refactoring )? Be able to name three bad smells. Be able to name three refactorings.

Upload: kristopher-mcbride

Post on 17-Dec-2015

216 views

Category:

Documents


0 download

TRANSCRIPT

Refactoring Overview What is refactoring? What are four good reasons to refactor? When should you refactor? What is a bad smell (relative to refactoring

)?

Be able to name three bad smells. Be able to name three refactorings.

Refactoring Changing the implementation of current code

without changing its functionality Why?

Improve clarity Ease the addition of functionality Remove duplication

What are four good reasons to refactor? improves the design of software makes the software easier to understand helps you find bugs helps you program faster

Basic Code Metrics Lines of Code

More lines of code = more maintenance. Of two programs of “equal functionality,” it is better to have fewer lines of code.

Philosophy: Consistent with the “refactoring” philosophy, we want code to be properly abstracted, less complex, and readable Number of Classes

To a point, more classes are preferred over less classes. Avoid “god class” or “blob class”

Coupling and Cohesion Excessive coupling

Detrimental to modular design and prevents reuse Larger number of couples, higher sensitivity to

changes in other parts of the design maintenance is more difficult

Any measure of disparateness of methods helps identify flaws in the design of the classes.

Cohesiveness of methods within a class is desirable, since it promotes encapsulation.

Lack of cohesion implies classes should probably be split into two or more subclasses.

Inheritance Depth of Inheritance Tree:

maximum length from the class node to the root/parent of the class hierarchy tree (number of ancestor classes. )

Tradeoff: Deep trees conceptual integrity problem (hard to

understand, so more complex) but greater reuse

Number of Children: Number of direct descendants (subclasses) for each class. Classes with large number of children are considered to be

difficult to modify and usually require more testing because of the effects on changes on all the children.

They are also considered more complex and fault-prone because a class with numerous children may have to provide services in a larger number of contexts and therefore must be more flexible.

Bad Smells in Code Duplicated code:

the same code (essentially) in more than one place, e.g.,

same expression in two methods of the same class

same expression in two sibling subclasses

Long parameter list: passing in lots of parameters to a method

(because global data is deemed evil) difficult to understand pass only enough so that the method can get to

everything it needs

Bad Smells in Code Large class:

a class trying to do too much e.g., too many instance variables factor out some related set of variables and

methods using Extract Superclass or Extract Subclass

Divergent change: when one class is commonly changed in different

ways for different reasons no single clear point for where to make changes probably two (or more) classes are better than

one use Extract Class

Sample Refactorings (cont.) Extract Component

You have one class doing the work that should be done by two—Create a new class and move the relevant fields and methods from the old class into the new class.

Bad Smells in Code Long method:

long, difficult-to-understand methods

want short, well-named methods need to aggressively decompose methods can often use Extract Method

Sample Refactorings (cont.) Extract Method

You have a code fragment that can be grouped together—Turn the fragment into a method whose name explains the purpose of the method.

Bad Smells in Code Shotgun surgery:

the opposite of divergent change making a change requires many little changes

to many different classes

consolidate the changes to a single class can use Move Method and Move Field balance with divergent change

Sample Refactorings (cont.) Move Method

A method is, or will be, using or used by more features of another class than the class on which it is defined—Create a method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether.

Bad Smells in Code Feature envy:

a method seems more interested in a class other than the one it is actually in

e.g., invoking lots of get methods

can use Move Method and Extract Method

Bad Smells in Code Data class:

classes that are all data (manipulated by other classes)

e.g., a Point record that has other classes manipulating its coordinates

in early stages, it’s all right to use public fields study usage and move behavior into data

classes can use Extract Method, Move Method,

Encapsulate Field

Sample Refactorings Self Encapsulate Field

You are accessing a field directly, but the coupling to the field is becoming awkward—Create getting and setting methods for the field and use only those to access the field

Bad Smells in Code Alternative classes with different

interfaces: methods that do the same thing but have

different signatures e.g., put() versus add()

can use Rename Method

Sample Refactorings (cont.) Rename Method

The name of a method does not reveal its purpose—Change the name of the method

Sample Refactorings (cont.) Parameterize Method

Several methods do similar things but with different values contained in the method body—Create one method that uses a parameter for the different values

Sample Refactorings Pull Up Field

Two subclasses have the same field—Move the field to a superclass

Pull up Constructor Body You have constructors on subclasses with

mostly identical bodies—Create a superclass constructor; class this from the subclass methods

Sample Refactorings (cont.) Form Template Method

You have two methods in subclasses that perform similar steps in the same order, yet the steps are different—Get the steps into methods with the same signature, so that the original methods become the same. Then you can pull them up.

Pull Up Method You have methods with identical results on

subclasses—Move them to the superclass.

Sample Refactorings (cont.) Substitute Algorithm

You want to replace an algorithm with one that is clearer—Replace the body of the method with the new algorithm

Replace Magic Number with Symbolic Constant You have a literal number with a particular

meaning—Create a constant, name it after the meaning, and replace the number with it.

Reading & Questions for Next Class

Catalog of refactorings http://www.refactoring.com/catalog/index.html

Refactoring Tools Easy to do manually Tools help it go faster Minimum standards

"Move Method" capability- move a method body from one class to another, AND alter the callers.

Ability to do various kinds of renaming, such as Rename Method, AND adjust in callers.

Move Class Extract Method- more than cut and paste. You have to

analyze the method, find any temporary variables, then figure out what to do with them.

http://www.refactoring.com/tools.html

Software Refactoring Example http://www.refactoring.com/rejectedExample.pdf http://www.refactoring.com

Refactoring Principles What problems or limitations are there

with refactoring? Potential limitations:

too much indirection changing published interfaces significant design changes possible? performance

Refactoring Principles When not to refactor:

when you should rewrite If you have no design to begin with!

when you are close to a deadline The quick and dirty solution is always faster in the

short term