Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.

Slides:



Advertisements
Similar presentations
Clean code. Motivation Total cost = the cost of developing + maintenance cost Maintenance cost = cost of understanding + cost of changes + cost of testing.
Advertisements

Structured Design. 2 Design Quality – Simplicity “There are two ways of constructing a software design: One is to make it so simple that there are obviously.
Test-Driven Development and Refactoring CPSC 315 – Programming Studio.
© 2010 Shawn A. Bohner Software Construction and Evolution - CSSE 375 Even more Bad Smells in Code Shawn & Steve Q1 Shawn & Steve Hint 
You want me to do what??? Refactoring legacy applications aka : fixing someone else’s “bad” code Niel Zeeman Team Foundation Consulting
Software Construction and Evolution - CSSE 375 Bad Smells in Code Shawn Bohner & Steve Chenoweth.
Introduction to Refactoring Excerpted from ‘What is Refactoring?’ by William C. Wake and Refactoring: Improving the Design of Existing Code by Martin Fowler.
George Blank University Lecturer. REFACTORING Improving the Design of Existing Code Supplement to Ian Sommerville, Software Engineering, Chapter 20 Prepared.
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
13-Jul-15 Refactoring II. Books Design Patterns is the classic book by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Basically a catalog.
Algorithm Programming Coding Advices Bar-Ilan University תשס " ו by Moshe Fresko.
Computer Science 240 Principles of Software Design.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Maintenance Refactoring and Code Smells. Where are we? Over the semester we have talked about Software Engineering. The overall goal of software engineering.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
GENERAL CONCEPTS OF OOPS INTRODUCTION With rapidly changing world and highly competitive and versatile nature of industry, the operations are becoming.
Refactoring Cristescu Marilena. Definitions Loose Usage: Reorganize a program(or something) As a noun: a change made to the internal structure of some.
Software Refactoring Part I: Introduction Bartosz Walter Advanced Object-Oriented Design Lecture 5.
Computer Science 240 © Ken Rodham 2006 Principles of Software Design.
LECTURE 38: REFACTORING CSC 395 – Software Engineering.
Refactoring Improving the structure of existing code Refactoring1.
Small changes to code to improve it. Refactoring Defined A change made to the internal structure of software to make it easier to understand and cheaper.
Refactoring (continued) Source: "Refactoring: Improving the Design of Existing Code", Martin Fowler.
Refactoring1 Refactoring DEPARTMENT OF COMPUTER SCIENCE AND SOFTWARE ENGINEERING CONCORDIA UNIVERSITY February 6, 2009.
SWE 316: Software Design and Architecture Objectives Lecture # 20 Improving the existing design: Refactoring SWE 316: Software Design and Architecture.
Improving the Quality of Existing Code Svetlin Nakov Telerik Corporation
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns IX Interpreter, Mediator, Template Method recap.
Refactoring1 Improving the structure of existing code.
Refactoring Deciding what to make a superclass or interface is difficult. Some of these refactorings are helpful. Some research items include Inheritance.
Introduction to Refactoring Jim Cooper Falafel Software.
Lecture 12 March 16, The Scope of a Variable What if there are two variables with the same name? –A local or block-local variable can have the same.
Incremental Design Why incremental design? Goal of incremental design Tools for incremental design  UML diagrams  Design principles  Design patterns.
Software Engineering CS3003 Lecture 4 Code bad smells and refactoring.
Refactoring. Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative.
Chapter 21 Test-Driven Development 1CS6359 Fall 2011 John Cole.
Refactoring 2. Admin Blackboard Quiz Acknowledgements Material in this presentation was drawn from Martin Fowler, Refactoring: Improving the Design of.
REFACTORINGREFACTORING. Realities Code evolves substantially during development Requirements changes 1%-4% per month on a project Current methodologies.
Module 3. Smells Between Classes Course: Refactoring.
1 Software Maintenance and Evolution CSSE 575: Session 3, Part 3 Dealing with Generalization Steve Chenoweth Office Phone: (812) Cell: (937)
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
Refactoring Advanced Software Engineering Dr Nuha El-Khalili.
Refactoring. Mathematics: Factor ● fac·tor – One of two or more quantities that divides a given quantity without a remainder, e.g., 2 and 3 are factors.
Refactoring1 Improving the structure of existing code.
Refactoring Agile Development Project. Lecture roadmap Refactoring Some issues to address when coding.
Pertemuan 12 Refactoring Mata kuliah: T0144 – Advanced Topics in Software Engineering Tahun: 2010.
Refactoring. 2 Process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal.
CSSE 375 Organizing Data – Part 1 Shawn and Steve Q1.
Object Oriented Metrics
Software Construction and Evolution - CSSE 375 Dealing with Generalization Steve and Shawn Left – In the 1990 movie “The Freshman,” Matthew Broderick,
Refactoring. DCS – SWC 2 Refactoring ”A change made to the internal structure of software to make it easier to understand and cheaper to modify without.
Module 9. Dealing with Generalization Course: Refactoring.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
ICONFINDER ICONFINDER Founded Django based web application -PostgreSQL -Elasticsearch -Amazon Elastic Compute.
A (Very) Simple Example Consolidate duplicate conditional fragments if (isSpecialDeal()) { total = price * 0.95; send (); } else { total = price * 0.98;
Principles and examples
Module Road Map Refactoring Why Refactoring? Examples
Object-Oriented Metrics
Refactoring SENG 301 © Refactoring: Improving the Design of Existing Code, Martin Fowler, Kent Beck Source:
Refactoring II 21-Sep-18.
Code Smells 1.
Decorator Pattern Richard Gesick.
Improving the structure of existing code
Refactoring and Code Smells
Refactoring Types Blake Duncan.
Refactoring II 5-Feb-19.
Software Metrics SAD ::: Fall 2015 Sabbir Muhammad Saleh.
Refactoring and Code Smells
Informatics 122 Software Design II
Refactoring.
Refactoring and Code Smells
Presentation transcript:

Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring )?  Be able to name three bad smells.  Be able to name three refactorings.

Refactoring  Changing the implementation of current code without changing its functionality  Why? Improve clarity Ease the addition of functionality Remove duplication  What are four good reasons to refactor? improves the design of software makes the software easier to understand helps you find bugs helps you program faster

Basic Code Metrics  Lines of Code More lines of code = more maintenance. Of two programs of “equal functionality,” it is better to have fewer lines of code.  Philosophy: Consistent with the “refactoring” philosophy, we want code to be properly abstracted, less complex, and readable Number of Classes  To a point, more classes are preferred over less classes.  Avoid “god class” or “blob class”

Coupling and Cohesion  Excessive coupling Detrimental to modular design and prevents reuse  Larger number of couples, higher sensitivity to changes in other parts of the design  maintenance is more difficult  Any measure of disparateness of methods helps identify flaws in the design of the classes.  Cohesiveness of methods within a class is desirable, since it promotes encapsulation.  Lack of cohesion implies classes should probably be split into two or more subclasses.

Inheritance  Depth of Inheritance Tree: maximum length from the class node to the root/parent of the class hierarchy tree (number of ancestor classes. ) Tradeoff:  Deep trees  conceptual integrity problem (hard to understand, so more complex)  but greater reuse  Number of Children: Number of direct descendants (subclasses) for each class. Classes with large number of children are considered to be difficult to modify and usually require more testing because of the effects on changes on all the children. They are also considered more complex and fault-prone because a class with numerous children may have to provide services in a larger number of contexts and therefore must be more flexible.

Bad Smells in Code  Duplicated code: the same code (essentially) in more than one place, e.g.,  same expression in two methods of the same class  same expression in two sibling subclasses  Long parameter list: passing in lots of parameters to a method (because global data is deemed evil) difficult to understand pass only enough so that the method can get to everything it needs

Bad Smells in Code  Large class: a class trying to do too much e.g., too many instance variables factor out some related set of variables and methods using Extract Superclass or Extract Subclass  Divergent change: when one class is commonly changed in different ways for different reasons no single clear point for where to make changes probably two (or more) classes are better than one use Extract Class

Sample Refactorings (cont.)  Extract Component You have one class doing the work that should be done by two—Create a new class and move the relevant fields and methods from the old class into the new class.

Bad Smells in Code  Long method: long, difficult-to-understand methods want short, well-named methods need to aggressively decompose methods can often use Extract Method

Sample Refactorings (cont.)  Extract Method You have a code fragment that can be grouped together—Turn the fragment into a method whose name explains the purpose of the method.

Bad Smells in Code  Shotgun surgery: the opposite of divergent change making a change requires many little changes to many different classes consolidate the changes to a single class can use Move Method and Move Field balance with divergent change

Sample Refactorings (cont.)  Move Method A method is, or will be, using or used by more features of another class than the class on which it is defined—Create a method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether.

Bad Smells in Code  Feature envy: a method seems more interested in a class other than the one it is actually in e.g., invoking lots of get methods can use Move Method and Extract Method

Bad Smells in Code  Data class: classes that are all data (manipulated by other classes) e.g., a Point record that has other classes manipulating its coordinates in early stages, it’s all right to use public fields study usage and move behavior into data classes can use Extract Method, Move Method, Encapsulate Field

Sample Refactorings  Self Encapsulate Field You are accessing a field directly, but the coupling to the field is becoming awkward—Create getting and setting methods for the field and use only those to access the field

Bad Smells in Code  Alternative classes with different interfaces: methods that do the same thing but have different signatures e.g., put() versus add() can use Rename Method

Sample Refactorings (cont.)  Rename Method The name of a method does not reveal its purpose— Change the name of the method

Sample Refactorings (cont.)  Parameterize Method Several methods do similar things but with different values contained in the method body—Create one method that uses a parameter for the different values

Sample Refactorings  Pull Up Field Two subclasses have the same field—Move the field to a superclass  Pull up Constructor Body You have constructors on subclasses with mostly identical bodies—Create a superclass constructor; class this from the subclass methods

Sample Refactorings (cont.)  Form Template Method You have two methods in subclasses that perform similar steps in the same order, yet the steps are different—Get the steps into methods with the same signature, so that the original methods become the same. Then you can pull them up.  Pull Up Method You have methods with identical results on subclasses—Move them to the superclass.

Sample Refactorings (cont.)  Substitute Algorithm You want to replace an algorithm with one that is clearer—Replace the body of the method with the new algorithm  Replace Magic Number with Symbolic Constant You have a literal number with a particular meaning— Create a constant, name it after the meaning, and replace the number with it.

Reading & Questions for Next Class  Catalog of refactorings

Refactoring Tools  Easy to do manually  Tools help it go faster  Minimum standards  "Move Method" capability- move a method body from one class to another, AND alter the callers.  Ability to do various kinds of renaming, such as Rename Method, AND adjust in callers.Rename Method  Move Class Move Class  Extract Method- more than cut and paste. You have to analyze the method, find any temporary variables, then figure out what to do with them. Extract Method 

Software Refactoring Example  

Refactoring Principles  What problems or limitations are there with refactoring?  Potential limitations: too much indirection changing published interfaces significant design changes possible? performance

Refactoring Principles  When not to refactor: when you should rewrite  If you have no design to begin with! when you are close to a deadline  The quick and dirty solution is always faster in the short term