Code Smells andRefactoring

Fowler says

• http://www.martinfowler.com//articles/workflowsOfRefactoring/• https://www.youtube.com/watch?v=vqEg37e4Mkw

Large Class• Class trying to do too much• Not focused, (no single responsibility principle)• Solution

• Extract Class• Extract Subclass

Long Parameter List• Procedural programming – Pass in as many parameters as you need• Reduced need with OOP • Solution

• Pass an object instead in the parameters• Method’s host class contains all the data • Method gets what it needs, nothing more nothing less

Refactoring• Replace Parameter with Method• Preserve Whole Object• Introduce Parameter Object

Divergent Change• One class changed in different ways for different reasons• Two objects in this case?• All change should be in one class?• Refactoring

• Extract Class

Shotgun Surgery• Opposite of divergent change• One kind of change involves touching several classes• Changes are all over the place and something gets missed• Refactoring

• Move method• Move field• Inline class (to bring behaviour together in a class)

Feature Envy• Objects should package data along with methods used on that data• Method in one class is too interested in data / methods in another

class• Refactoring

• Move method• If only part of the method has the issue, then Extract Method and Move method

• Patterns• Strategy• Visitor• Self Delegation [Kent Beck] [Smalltalk]

Data Clumps• A few data items “hanging out” together• Examples;

• fields in classes• Parameters in multiple methods

• Refactoring• Extract Class to turn clumps into objects• Introduce parameter object to slim them down and simplify• Preserve whole object to slim them down and simplify

Primitive Obsession• Do we really need classes for Numbers, Strings and Dates?• Money classes, Telephone numbers, ZIP/PIN Codes• “Overhead” of creating these – inertia• Refactoring

• Replace Data Value with Object on individual data values• Replace Type Code with Class if the value does not affect behaviour• Replace Type Code with Subclasses if conditionals that depend upon type code present• Replace Type Code with State/Strategy , if conditionals depending upon type code present• Extract class if group of fields are going together• Introduce parameter object if primitivies in parameter lists• Replace Array with Object if array needs similar refactoring into an object

Switch statements• Not really “Object oriented” code• Should be polymorphism instead!• Solution

• Switches are mostly on Type Code• Each “Type” corresponds to a class

• Refactoring• Extract Method to extract the switch statement and Move Method to move it to specified

class• Decide on Replace Type Code with Polymorphism or Replace Type Code with

State/Strategy• Non-changing case affecting a single method, use Replace Parameter with Explicit Methods

Parallel Inheritance Hierarchies• Special case of Shotgun Surgery• Every time a subclass of one class is made, a subclass of another is

needed• Solution

• Eliminate duplication , instances of one hierarchy refer to another

• Refactoring• Move method and Move field to eliminate one hierarchy

Lazy Class• Class has no business being there?• Planned changes but not needed/ not in use• Downsized by refactoring• Really not doing enough• Refactoring

• Collapse Hierarchy• Inline Class to take care of useless components

Speculative Generality• Developers with Sharp noses!• Hooks and Special cases to handle generally unrequired stuff• Not used and usually looks badly written• Refactoring

• Abstract classes sitting around, use Collapse Hierarchy• Remove unnecessary delegation with Inline Class• Methods with unused parameters, use Remove Parameter• Methods with odd abstract names, use Rename Method

Temporary Field• Instance variables instead of parameters?• Set only in “certain” circumstances• Complicated algorithm requiring several variables• Refactoring

• Extract Class to create a home for these variables• Introduce null object to create a component for when these variables are not valid

Message Chains• Client asks for one object• One objects asks for one more.. And so on…• Long getThis… methods/ sequence of temporary variables• Client coupled to the structure of the navigation• Refactoring

• Hide Delegate at various points in the chain (judicious!)• Extract Method/ Move method to move it down the chain

Middle man• Delegation is good• Only upto a point• Too much delegation, repeatably?• Refactoring

• Remove Middle Man to talk to the object that really knows what’s going on• Inline method if too few methods that don’t really do much, inline them into the caller• Replace Delegation with inheritance to make the middle man into a subclass

Inappropriate Intimacy• Classes too close, know too much about each other• Just NEED to be refactored• Refactoring

• Move method and Move field to separate the tightly coupled pieces• Check for Change Bidirectional association to Unidirectional• Extract Class for common interests of both classes• Hide Delegate to introduce a go-between• Replace Inheritance with Delegation when the subclass is way too cosy with parent

Alternative Classes with Different Interfaces• Different methods with different interfaces that do the same thing• Refactoring

• Rename Method for classes with different interfaces that do the same thing• Repeatedly use Move method until the protocols are the same.

Incomplete Library Class• Just the method you did not need are there, so why use the library?• Refactoring

• Just a couple of methods or so? Use Introduce Foreign Method• A whole lot more of extra behaviour, Use Local Extension

Data Classes, value objects• Should not have public fields• If they do, manipulated excessively, so need data hiding• Refactoring

• Encapsulate field for fields• Encapsulate Collection if no properly hidden collections• Remove Setting Method on any field that should not be changed• Move method to move behaviour into the Data Class• Extract method to create a method that can be moved• Hide method if needed for getters and setters

Refused Bequest• Subclasses don’t want or need all the methods or features• Just need what they need• Wrong Hierarchy!• Refactoring

• Create a new sibling class• Push down method and Push down field used to create methods/data in the sibling• Use Sparingly• Subclass rewriting the interface -> Real bad smell.Use Replace Inheritance with

Delegation to sidestep.

Comments• Not always a bad smell• But don’t use them as deodorant!• Refactor to remove all the bad code• Check whether comment is needed, then remove if not.

• If comments needed for a block of code, then Extract Method• If extracted method needs comments, use Rename Method• Talk about required state of system, Use Introduce Assertion

Thank you! References:

Refactoring: Improving the design of existing code (Fowler, Martin)

refactoring.com/catalog