REFACTORING

1. REFACTORING Improving the Design of Existing Code Atakan Şimşek e1298306

2. Outline • Definition of Refactoring • Why&When Refactor? • Refactoring Steps • Refactoring Examples • Bad Smells • Definiton • Solution • Conclusion

3. Definition • Refactoring (noun): Improving the design of existing code without changing the code's observable behavior.

4. Some Definitions • [Fowler] a change made to the internal structure ofsoftware to make it • easier to understand • cheaper to modify without changing its observable behavior • [Beck] Improving the design after it has been written.

5. Why Refactor ? • Easier to understand • It becomes easy for others to understand. • To find the bugs • Finding the Bugs in the program.

6. To reduce • Software maintenance costs • To faciliate • Future changes

7. To program faster • Code complexity tends toincrease rapidly over time(Patching new functionalities) • Development slows down • Refactoring helps keepingcomplexity under control • Developmentproceed more rapidly

8. When to Refactor ? • When you add a function • Helps you to understand the code when modifying. • Sometimes the existing design does not allow you to easily add the feature. • When you need to fix a bug • If it is difficult to trace an error: Code was not clear enough for you to see the bug in the first place.

9. When you do a Code Review When you detect a “bad smell” (an indication thatsomething is wrong) in the code

10. Refactor? or NOT? • Code does not work : NOT • Code has some bugs : REFACTOR • Very Close to Deadline : NOT • There are bad smells : REFACTOR

11. Bad Smells

12. Where Can We Use? Producer Side Consumer Side COSE

13. Conditions of Refactoring • Refactoring implies working incrementally • Making changes to the program in small steps • In between run the unit tests regularly If you make a mistake it's easy to back out.

14. Steps to Refactoring • Analysis, helps to identify the code • Identify problems in code by review using bad smells of code • Introduce a refactoring • Test

15. Add Parameter Change Association Reference to value Value to reference Collapse hierarchy Consolidate conditionals Procedures to objects Decompose conditional Encapsulate collection Encapsulate downcast Encapsulate field Extract class Extract Interface Extract method Extract subclass Extract superclass Form template method Hide delegate Hide method Inline class Inline temp Introduce assertion Introduce explain variable Introduce foreign method Refactorings

16. Refactoring examples • Change Association • Encapsulate Field • Replace Number with Constants • Compose Conditions • Extract Class

17. We have a two-way association but one class no longer needs features from the other. Bi-directional Association to Unidirectional

18. Self Encapsulate Field • Create getting and setting methods for the field and use only those to access the field. • private int _low, _high; • boolean includes (int arg) • { • return arg >= _low && arg <= _high; • } • private int _low, _high; • boolean includes (int arg) • { • return arg >= getLow() && arg <= getHigh(); • } • int getLow() {return _low;} • int getHigh() {return _high;}

19. Replace Magic Number with Symbolic Constant • Create a constant, name it after the meaning, and replace the number with it. double potentialEnergy(double mass, double height) { return mass * 9.81 * height; } double potentialEnergy(double mass, double height) { return mass * GRAVITATIONAL_CONSTANT * height; } static final double GRAVITATIONAL_CONSTANT = 9.81;

20. When we have a complicated conditional (if-then-else) statement. Consolidate conditionals double disabilityAmount() { if (_seniority < 2) return 0; if (_monthsDisabled > 12) return 0; if (_isPartTime) return 0 // compute the disability amount double disabilityAmount() { if (isNotEligableForDisability()) return 0; // compute the disabilityamount

21. You have one class doing work that should bedone by two. Create a new class and move the relevant fields Extract Class

22. Bad Smells in Code • Parallel Interface Hierarchies • Lazy Class • Speculative Generality • Temporary Field • Message Chains • Middle Man • Inappropriate Intimacy • Incomplete Library Class • Data Class • Refused Bequest • Duplicated Code • Long Method • Large Class • Long ParameterList • Divergent Change • Shotgun Surgery • Feature Envy • Data Clumps • Primitive Obsession • Switch Statements

23. Few solutions to Bad Smells • Duplicated Code: • If you see the same code structure in more than one place

24. Duplicated Code(cont.) • Bugs copied as well • Increase maintenance cost solution: perform EXTRACT METHOD and invoke the code from both places.

25. Long Parameter List An object invokes a method, then passes the result as a parameter for a method. solution: • Use REPLACE PARAMETER with METHOD • Remove the parameter and let the receiver invoke the same method with sender.

26. Long Method The longer a procedure is the more difficult it is to understand. solution: perform EXTRACT METHOD

27. Conclusion: Refactoring is useful to any program that has at least one of the following shortcomings: • Programs that are hard to read • Programs that have bad smells • Programs that require additional behavior

28. References: • More Information can be found • http://www.refactoring.com/ • http://www.refactoring.be/ • Refactoring: Improving the Design of Existing Code By Martin Fowler