아름다운프로'의 JTOP.org 백업사이트

Replace Delegation with Inheritance

Replace Data Value with Object

Replace Constructor with Factory Method

Additional Comments

Replace Conditional with Visitor

Replace Conditional with Polymorphism

Replace Assignment with Initialization

Motivation

Mechanics

• Move the declaration of the variable to where that variable is first used,
  just before the assignment, making sure that you haven't reduced the scope
  of the variable so that it isn't in scope at some other place where it
  is used


• Compile and test  


• Replace the declaration and assignment with a direct initialization


• Compile and test  


• If appropriate, declare the temp as final, and compile and test again.

Example

Start with this code.

void foo() {
        int i;
        // ....
        i = 7;
}

The first move is to move the declaration of the variable to just before
where it is assigned to:


void foo() {
        // ....
        int i;
        i = 7;
}

I can now compile and test this. The most common mistake is that you have reduced the scope of the variable so that it no longer is in scope at some other place where it is used. Fortunately C++ and Java compilers will give you and error if this has happened.

Then it is time to replace the declaration + assignment with the initialization:

void foo() {
        // ....
        int i = 7;
}

If this also compiles and runs as before, then it is the end of the refactoring.

However if the value of i doesn't change, then it's a good idea to make that explicit by declaring i as final


void foo() {
        // ....
        final int i = 7;
}

Replace Array with Object

Rename Method

Remove Setting Method

A field should be set at creation time and never altered.

Remove any setting method for that field.

Corrections

Using Final

Contributors

• Paul Haahr

Remove Parameter

Remove Middle Man

Remove Double Negative

Motivation

Mechanics

• If you don't have a method with the opposite sense, create one. The body can just call the original (you can fix that later).


• Compile


• Replace each double negative with a call to the new function


• Compile and test after each replace


• If the negative form of the method isn't used elsewhere, use Inline Method to inline it into the positive form


• If you do need both forms, consider moving the body of the negative form over to the positive and reversing its sense, and then have the negative method call the positive one.


• Consider using Substitute Algorithm if the positive form is difficult to understand.

Remove Control Flag

Remove Assignments to Parameters

Refactor Architecture by Tiers

Reduce Scope of Variable

Motivation

Mechanics

• Move the declaration of the variable to the scope where that variable is used, making sure that you haven't reduced the scope of the variable too much, so that it isn't in scope at some other place where it is used


• Compile and test  

Additional Comments

Push Down Method

Behavior on a superclass is relevant only for some of its subclasses.

Move it to those subclasses.

Push Down Field

A field is used only by some subclasses.

Move the field to those subclasses.

Pull Up Method

You have methods with identical results on subclasses.

Move them to the superclass.

Pull Up Field

Two subclasses have the same field.

Move the field to the superclass.

Pull Up Constructor Body

Preserve Whole Object

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.

Corrections

Clarifying the Mechanics

Contributors

• Bernd Kahlbrandt

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 new method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether.

Additional Comments

Move Field

Move Class

Motivation

Mechanics

• Move the class to its new folder on the source tree.


• Remove any class files generated from compiling this class at its old location.


• Alter the package statement in the source file to reflect the new package.


• Create import statements for any dependant classes in original package.


• Compile and test the class in its new package, updating and moving unit tests as required using this same method.


• Alter, and create in some cases, the import statements on any dependee class. Note this is easier if wide imports are not used.


• Check for classes that might dynamically instantiate this class using java.lang.reflect or the ResourceBundle api. Also look for code that might reference this class as an absolute class literal.


• Compile and test all code that was dependant on the original class.


• Consider applying
  Extract Package when you have many classes of different functionality in a given package.

Example

Lets look at the header of StringUtil


package org.davison.ui

// imports

public class StringUtil

...

We move the file and change the package header.


package org.davison.util

// imports

public class StringUtil

...

I can now compile and unit test this class in its new package. If the unit tests are in a different package class file then they might need to be updated.

I can now go on to update the dependant classes. For example here I update the import statements, I have not used a wide imports in this example but the principle is the same.


package org.davison.log

// imports

import org.davison.ui.StringUtils;

// more imports

public class Logger

...


This becomes:


package org.davison.log

// imports

import org.davison.util.StringUtils;

// more imports

public class Logger

...



Again compile and test this new class with the imports.

As mentioned before there are other ways of dynamically loading classes. You may have to look for class literals and strings constants containing the fully qualified name of the old class.




// A class literal

public Class m_utils = org.davison.ui.StringUtils.class;

// A dynamically loaded class

public Class m_utils = Class.forName("org.davison.ui.StringUtils");

// A loaded resource bundle

public ResourceBundle m_bundle = ResourceBundle.getBundle(
   "org.davison.ui.StringUtils");




These can be fixed using simple find and replaces, these dynamic examples will also be found using the units tests for all classes.





// A class literal, this will be found by the compiler.

public Class m_utils = org.davison.util.StringUtils.class;

// A dynamically loaded class

public Class m_utils = Class.forName("org.davison.util.StringUtils");

// A loaded resource bundle

public ResourceBundle m_bundle = ResourceBundle.getBundle(
   "org.davison.util.StringUtils");





One all static and dynamic cases have been dealt with, and all unit tests have run. The refactoring is complete.

Additional Comments

Move Business Logic to Session

Merge Session Beans

Localize Disparate Logic