REFACTOR

WHAT IS REFACTORING?

Refactoring consists in modifying software to improve its readibility, maintainability and extensibility without changing what it actually does

noun: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior

verb: to restructure software by applying a series of refactorings without changing its observable behavior

https://martinfowler.com/books/refactoring.html

MARTIN FOWLER DEFINITION (AUTHOR OF REFACTORING.COM)

Refactoring isn't another word for cleaning up code - it specifically defines one technique for improving the health of a code-base. I use "restructuring" as a more general term for reorganizing code that may incorporate other techniques.

WHY REFACTOR?

It’s like I want to go 100 miles east but instead of just traipsing through the woods, I’m going to drive 20 miles north to the highway and then I’m going to go 100 miles east at three times the speed I could have if I just went straight there. When people are pushing you to just go straight there, sometimes you need to say, “Wait, I need to check the map and find the quickest route.” The preparatory refactoring does that for me.

Keep the external quality but improve the internal quality

Refactoring involves changing things, hence it can (and so it will!) introduce problems.

Be ready for them, take the opportunity to automate tests, do it in small incremental steps, etc.

Refactoring Risks

Keep the external quality but improve the internal quality

EXAMPLES????

Keep the external quality but improve the internal quality

Extract code to new/other method/classes

Move methods

Rename methods/objects/attributes

add attributes to classes/methods

Change Classes Structure

EXAMPLES

Example 1 - Consolidate Conditional Expression

Example 2 - Decompose Conditionals

Example 3

Move a method from class A to class B if uses/is being used by more features in class B

Example 4

Introduce Null Object

Imagine in your software you are always checking if instances of an object are null:

Customer c = findCustomer(...);

...

if (customer == null) {
  name = "occupant";
} else {
  name = customer.getName();
}

...

if (customer == null) {
...
}

Duplicating code, makes it more difficult to be maintained, more complex, more difficult to be understood

Example 4

Introduce Null Object

public class NullCustomer extends Customer {

   public String getName() {
	return “occupant”
}

------------------------------------------------------------

Customer c = findCustomer()
name = c.getName()

http://www.tutorialspoint.com/design_pattern/null_object_pattern.htm

Example 5

Switch Statements

switch statements are very rare in properly designed object-oriented code
Therefore, a switch statement is a simple and easily detected “bad smell”
Of course, not all uses of switch are bad
- Switch statement should not be used to distinguish between various kinds of objects.
There are several well-defined refactorings for this case.
- The simplest is the creation of subclasses

Example 5

Switch Statements

class Animal {
   final int MAMMAL = 0, BIRD = 1, REPTILE = 2;
   int myKind;  // set in constructor
   ...
   String getSkin() {
      switch (myKind) {
         case MAMMAL: return "hair";
         case BIRD: return "feathers";
         case REPTILE: return "scales";
         default: return "integument";
      }
   }
}

Example 5

Switch Statements

class Animal {
   final int MAMMAL = 0, BIRD = 1, REPTILE = 2;
   int myKind;  // set in constructor
   ...
   String getSkin() {
      switch (myKind) {
         case MAMMAL: return "hair";
         case BIRD: return "feathers";
         case REPTILE: return "scales";
         default: return "integument";
      }
   }
}

class Animal {
     String getSkin() { return "integument"; }
}
class Mammal extends Animal {
     String getSkin() { return "hair"; }
}
class Bird extends Animal {
     String getSkin() { return "feathers"; }
}
class Reptile extends Animal {
     String getSkin() { return "scales"; }
}

- Adding a new animal type, such as Amphibian, does not require revising and recompiling existing code

- Mammals, birds, and reptiles are likely to differ in other ways, and we’ve already separated them out (so we won’t need more switch statements)

- We’ve gotten rid of the flags we needed to tell one kind of animal from another

- Basically, we’re now using Objects the way they were meant to be used

Advantages:

A lot of examples

https://github.com/RefactoringGuru/refactoring-examples/tree/master/simple/java

Identifying aspects to refactor

"Bad Smells"

Bad Smells: is a term coined by Martin Fowler

https://www.doc.ic.ac.uk/~susan/475/unmain.html

https://www.se.rit.edu/~tabeec/RIT_441/Resources_files/How%20To%20Write%20Unmaintainable%20Code.pdf

https://github.com/Droogans/unmaintainable-code

Developing Stinky Code

BAD SMELLS - I

DUPLICATED CODE: Bad because you need to mantain the code as many times as it's duplicated
LONG METHOD: Bad because they are more difficult to be understood, more error prone, etc.
LARGE CLASS: If a class is doing too much, OO is useless.
LONG PARAMETER LIST: Hard to understand
DATA CLASS: Class without behaviour implementation

BAD SMELLS - II

DIVERGENT CHANGES / SHOTGUN SURGERY: Two sides of the coin:
- No matter what you need to change in your code, a class must be always modified.
- One change/new feature requires changing a lot of things in different places.
FEATURE ENVY: Method is more interested in a class than in its own class.
REPEATED SWITCH STATEMENTS: Symptom of not using properly OO programming

https://sourcemaking.com/refactoring/smells