Slide 1REFACTORINGDefinitionContinued…Where did Refactoring come from ?Why Refactor ?Slide 7When to Refractor ?Slide 9Properties of RefactoringDesign AttributesSteps to RefactoringSlide 13A few RefactoringsRefactoring examplesContinued..Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Bad Smells in CodeFew solutions to Bad SmellsSlide 30Slide 31Slide 32Benefits of RefactoringSlide 34Refactoring RisksCosts of RefactoringSlide 37Slide 38When to put Off Refactoring ?BibliographyGeorge BlankUniversity LecturerREFACTORINGImproving the Design of Existing CodeSupplement to Ian Sommerville, Software Engineering, Chapter 20 Prepared by : Sunil ManoharanDefinition•Refactoring is changing a software system by improving its internal structure without changing its external behavior, i.e. it is a technique to restructure the code in a disciplined way.•It makes the software easier to understand and cheaper to modify.Continued…•For a long time it was a piece of programmer lore, done with varying degrees of discipline by experienced developers, but not passed on in a coherent way. •Refactoring is an overhead activity.Where did Refactoring come from ?•Two of the first people to recognize the importance of refactoring were Kent Beck and Ward Cunningham•They worked with Smalltalk from the 80's onward.•Refactoring has always been an important element in the Smalltalk community.•Ralph Johnson's work with refactoring and frameworks has also been an important contribution.Why Refactor ?•Improves the design of software Without refactoring the design of the program will decay. Poorly designed code usually takes more to do the same things, often because the does the same thing in different places•Easier to understand In most software development environments, somebody else will eventually have to read your code so it becomes easy for others to comprehend.Continued…•To find the bugsIt helps in finding the Bugs present in the program.•To program fasterIt helps us to do the coding/programming faster as we have better understanding of the situation.When to Refractor ?•When you add a functionHelps you to understand the code you are modifying.Sometimes the existing design does not allow you to easily add the feature.•When you need to fix a bugIf you get a bug report its a sign the code needs refactoring because the code was not clear enough for you to see the bug in the first place.Continued…•When you do a Code Review - Code reviews help spread knowledge through the development team.- Works best with small review groupsProperties of Refactoring•Preserve Correctness•One step at a time•Frequent TestingDesign Attributes•Abstraction (information hiding)•Flexibility•Clarity•IrredundancySteps to Refactoring•Pareto analysis helps to identify heavily used or time consuming code.•Refactoring begins by designing a solid set of tests for the section of code under analysis.•Identify problems in code by review using bad smells of code.•Introduce a refactoring and test.Continued…•The steps taken when applying the refactoring should be:- Small enough to oversee the consequences they have.- Reproduceable to allow others to understand them.- Generalized in a way, that they are more a rule that can be applied to any structure.- Written down to allow sharing these steps and to keep a reference, with step by step instructions how to apply them.A few Refactorings•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 methodRefactoring examples •Add a Parameter : When a method needs more information from its caller.Continued..•Bi-directional Association to Unidirectional : We have a two-way association but one class no longer needs features from the other.Continued…•Change Reference to Value : When we have a reference object that is small, immutable, and awkward to manage.Continued…•Change Value to Reference : When we have a class with many equal instances that we want to replace with a single object.Continued..•Collapse Hierarchy : As superclass and subclass are not very different.Continued…•Consolidate conditionals :double disabilityAmount() { if (_seniority < 2) return 0; if (_monthsDisabled > 12) return 0; if (_isPartTime) return // compute the disability amount double disabilityAmount() { if (isNotEligableForDisability()) return 0; // compute the disability amountContinued…•Decompose Conditionals : When we have a complicated conditional (if-then-else) statement.if (date.before (SUMMER_START) || date.after(SUMMER_END))charge = quantity * _winterRate + _winterServiceCharge;else charge = quantity * _summerRate; if (notSummer(date)) charge = quantity * _winterRate + _winterServiceCharge;else charge = summerCharge (quantity);Continued..•Encapsulate Collection : When a method returns a collectionContinued..•Encapsulate Downcast : When a method returns an object that needs to be downcasted by its callers.Object lastReading() {return readings.lastElement();} Reading lastReading() {return (Reading) readings.lastElement();}Continued…•Extract Class : When we have one class doing the work that should be done by two.Continued…•Extract Method : When we have a code fragment that can be grouped together. void printOwing() { printBanner();7//print details System.out.println ("name:" + _name); System.out.println ("amount" + getOutstanding());} void printOwing() {printBanner();printDetails(getOutstanding());} void printDetails (double outstanding) { System.out.println ("name:" + _name); System.out.println ("amount:" + outstanding);}Continued…•Hide Delegate : When a client is calling a delegate class of an object.Continued…•Inline Class : When a class isn't doing very much.Bad Smells in Code•Duplicated Code•Long Method•Large Class•Long Parameter List•Divergent Change•Shotgun Surgery•Feature Envy•Data Clumps•Primitive Obsession•Switch Statements Parallel Interface Hierarchies