340 likes | 686 Views
REFACTORING. Improving the Design of Existing Code. Atakan Şimşek e1298306. Outline. Definition of Refactoring Why&When Refactor? Refactoring Steps Refactoring Examples Bad Smells Definiton Solution Conclusion. Definition. Refactoring (noun):
E N D
REFACTORING Improving the Design of Existing Code Atakan Şimşek e1298306
Outline • Definition of Refactoring • Why&When Refactor? • Refactoring Steps • Refactoring Examples • Bad Smells • Definiton • Solution • Conclusion
Definition • Refactoring (noun): Improving the design of existing code without changing the code's observable behavior.
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.
Why Refactor ? • Easier to understand • It becomes easy for others to understand. • To find the bugs • Finding the Bugs in the program.
To reduce • Software maintenance costs • To faciliate • Future changes
To program faster • Code complexity tends toincrease rapidly over time(Patching new functionalities) • Development slows down • Refactoring helps keepingcomplexity under control • Developmentproceed more rapidly
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.
When you do a Code Review When you detect a “bad smell” (an indication thatsomething is wrong) in the code
Refactor? or NOT? • Code does not work : NOT • Code has some bugs : REFACTOR • Very Close to Deadline : NOT • There are bad smells : REFACTOR
Where Can We Use? Producer Side Consumer Side COSE
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.
Steps to Refactoring • Analysis, helps to identify the code • Identify problems in code by review using bad smells of code • Introduce a refactoring • Test
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
Refactoring examples • Change Association • Encapsulate Field • Replace Number with Constants • Compose Conditions • Extract Class
We have a two-way association but one class no longer needs features from the other. Bi-directional Association to Unidirectional
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;}
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;
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
You have one class doing work that should bedone by two. Create a new class and move the relevant fields Extract Class
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
Few solutions to Bad Smells • Duplicated Code: • If you see the same code structure in more than one place
Duplicated Code(cont.) • Bugs copied as well • Increase maintenance cost solution: perform EXTRACT METHOD and invoke the code from both places.
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.
Long Method The longer a procedure is the more difficult it is to understand. solution: perform EXTRACT METHOD
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
References: • More Information can be found • http://www.refactoring.com/ • http://www.refactoring.be/ • Refactoring: Improving the Design of Existing Code By Martin Fowler