Apr 18, 2023

Refactoring III

General philosophy

A refactoring is just a way of rearranging code Refactorings are used to solve problems If there’s no problem, you shouldn’t refactor

The notion of “bad smells” is a way of helping us recognize when we have a problem

Familiarity with bad smells also helps us avoid them in the first place

Refactorings are mostly pretty obvious Most of the value in discussing them is just to bring them into our

“conscious toolbox” Refactorings have names in order to crystallize the idea and help us

remember it

Duplicated code

Martin Fowler refers to duplicated code as “Number one in the stink parade” The usual solution is to apply Extract Method: Create a single

method from the repeated code, and use it wherever needed We’ve discussed some of the details of this (adding a

parameter list, etc.) This adds the overhead of method calls, thus the code

gets a bit slower Is this a problem?

Making code faster “We should forget about small efficiencies, say about 97% of the time: premature

optimization is the root of all evil.” -- Tony Hoare

Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson

“More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason--including blind stupidity.” -- W.A. Wulf

Very few programs actually need to be faster The only two examples I can think of are game graphics and Blackboard

Donald E. Knuth pointed out (in 1970) that it is essentially impossible to predict where the bottlenecks are in a program--you need to use a profiler to actually measure what the code is doing

Long methods

Another “bad smell” is the overly long method Almost always, you can fix long methods by applying

Extract Method Find parts of the method that seem to perform a single task,

and make them into a new method Potential problem: You may end up with lots of

parameters and temporary variables Temporaries: Consider Replace Temp With Query Parameters: Try Introduce Parameter Object and Preserve

Whole Object If all else fails, use Replace Method With Method Object

Temporary variables

According to Fowler, temporary variables “tend to encourage longer methods, because that’s the only way you can get at the temp.”

If the code fragment you want to extract into a method contains references to temporary variables whose scope overlaps the fragment, you have to somehow provide access to that temporary variable

Solution: Use the Replace Temp With Query refactoring

Replace Temp With Query Create a method to compute or access the temporary variable

Example (from Fowler):

Replace: double basePrice = quantity * itemPrice; if (basePrice > 1000) return basePrice * 0.95; else return basePrice * 0.98;

with: if (basePrice() > 1000) return basePrice() * 0.95; else return basePrice() * 0.98; ... double basePrice() { return quantity * itemPrice; }

Introduce Parameter Object

Problem: You have a method that requires a long parameter list You may have a group of parameters that go naturally together If so, make them into an object

Example: Replace public void marry(String name, int age, boolean gender, String name2, int age2, boolean gender2) {...}with public void marry(Person person1, Person person2) {...}

Preserve Whole Object

Problem: You have a method that requires a long parameter list

If you are passing in multiple values from the same object, pass the object in instead

Example: Replace sendBill(customer.name, customer.address, customer.order, amount);with sendBill(customer, amount);

Replace Method With Method Object If: you have a long method that uses local variables, and you

can’t use Extract Method, Then: turn the method itself into a object

Create a new class, named after the method Give the new class the following fields:

A final field to hold the object that the method originally came from A field for each temporary variable and parameter in the method

Write a constructor that takes as parameters the original object and the parameters of the original method

Copy the original method into the new class If you need anything from the original object, you have a reference to it

All the old local variables are now fields of the object This makes it easy to decompose the long method into as many methods

as you want

Long parameter list

Long parameter lists are difficult to understand, difficult to remember, and make it harder to format your code nicely

We’ve already discussed some solutions, such as Introduce Parameter Object

Another solution, which we won’t go into in detail, is called Replace Parameter With Method The idea is that you shouldn’t pass a parameter into a method

if the method has enough information to compute the parameter for itself

Large class

Classes can get overly large Too many instance variables More than a couple dozen methods Seemingly unrelated methods in the same class

Possible refactorings are Extract Class and Extract Subclass

A related refactoring, Extract Interface, can be helpful in determining how to break up a large class

Extract Class

Extract Class is used when you decide to break one class into two classes Classes tend to grow, and get more and more data Good signs:

A subset of the data and a subset of the methods seem to go together A subset of the data seems to be interdependent

Useful tests: If you removed a method or a particular piece of data, what other

fields and methods would become nonsense? How is the class subtyped?

The actual refactoring technique involves creating a new (empty) class, and repeatedly moving fields and methods into it, compiling and testing after each move

Extract Subclass

Extract Subclass is used when some behaviors of a class are used for certain instances, but not others

If you have a “type code” that is used to distinguish between types of objects, this suggests that a subclass may be appropriate

The type code can be eliminated when you create the subclass Extract Subclass should not be used when the instances vary in more

than one respect

The basic steps are: Define the subclass, provide constructors, and use Push Down Method and Push Down Field refactorings

We won’t go into the details of these refactorings

Extract Interface

Extract Interface is used when two or more classes share a related set of behaviors For example, you might provide two or more types of

services to your customers, with similar but separate billing needs

This suggests a Billable interface I hire J&K landscaping to do routine mowing and yard

clearing; they also remove fallen trees, but bill the job differently

Java’s Collections make heavy use of interfaces, as you have to do similar things (add, remove, iterate over) the elements of Sets, Vectors, Stacks, etc.

Feature envy

“Feature envy” is when a method makes heavy use of data and methods from another class Use Move Method to put it in the more desired class

Sometimes only part of the method makes heavy use of the features of another class Use Extract Method to extract those parts that belong in the

other class

Primitive Obsession

Many programmers are reluctant to introduce “little” classes that represent things easily represented by primitives—telephone numbers, zip codes, money amounts, ranges (variables with upper and lower bounds)

If your primitive needs any additional data or behavior, consider turning it into a class For example, you may want to format your primitive in a

special way, such as (215)898-0587 or 19104-6389

More bad smells, I

Divergent Change: One class keeps being changed in different ways for different reasons Identify each cause of change, and use Extract Class to isolate

the required changes for that cause

Shotgun Surgery: Every time you make a change, you have to make a lot of little changes in various classes Group all the changes into a single class with Move Method

and Move Field

More bad smells, II

Data Clumps: Data fields that occur together in numerous places Use Extract Class to group the fields into a single object Look for parameter lists that can be abbreviated by using this new object,

and use Introduce Parameter Object or Preserve Whole Object

Switch Statements: A switch statement is used to do different things based on some type flag

Perhaps the types should be subclasses Use Extract Method to isolate the switch statement Use Move Method to put it into the class that needs these types Use Replace Type Code with Subclasses

Testing for null According to Fowler:

“The essence of polymorphism is that instead of asking an object what type it is and then invoking some behavior based on the answer, you just invoke the behavior. The object, depending on its type, does the right thing.”

Unfortunately, if the object might be null, you have to test it first, or risk getting a NullPointerException

An occasional test for null isn’t so bad, but a lot of them will clutter up the code and be a nuisance

Solution: Introduce a “null object”—a real object of the correct class (or a subclass of the correct class) that has the appropriate behavior

Refactoring in Eclipse 3.2.1

The End