Refactoring 2. Admin Blackboard Quiz Acknowledgements Material in this presentation was drawn from Martin Fowler, Refactoring: Improving the Design of.

Slides:



Advertisements
Similar presentations
Test Driven Refactoring by Andreas Thies. XP Test Driven Refactoring2 Overview Refactoring Bad Smells Unit Tests Unit Tests and Refactoring Special.
Advertisements

Module 7. Simplifying Conditional Expressions Course: Refactoring.
Clean code. Motivation Total cost = the cost of developing + maintenance cost Maintenance cost = cost of understanding + cost of changes + cost of testing.
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
Gregor Gisler-Merz BrownBag Session Refactoring.
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
Lectures 17 and 18 A Refactoring Micro-Example FOR0383 Software Quality Assurance 5/16/20151Dr Andy Brooks Refactoring is really easy using this tool.
Software Construction and Evolution - CSSE 375 Bad Smells in Code Shawn Bohner & Steve Chenoweth.
1 Software Maintenance and Evolution CSSE 575: Session 1, Part 4 Even more Bad Smells in Code Steve Chenoweth Office Phone: (812) Cell: (937)
Steve Chenoweth Office Phone: (812) Cell: (937)
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.
XP and Refactoring David Talby. Development Methodologies The Software Crisis – 84% of software projects are not on time – 31% of software projects never.
25-Jun-15 Refactoring III. General philosophy A refactoring is just a way of rearranging code Refactorings are used to solve problems If there’s no problem,
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
What is Refactoring? CSE301 University of Sunderland Harry R. Erwin, PhD.
Refactoring Cristescu Marilena. Definitions Loose Usage: Reorganize a program(or something) As a noun: a change made to the internal structure of some.
Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1.
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.
Refactoring - A disciplined approach to rework for better design.
Software Engineering 1 Object-oriented Analysis and Design Chap 21 Test-Driven Development and Refactoring.
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.
SWE 316: Software Design and Architecture Objectives Lecture # 20 Improving the existing design: Refactoring SWE 316: Software Design and Architecture.
When and How to Refactor? Refactoring Patterns Alexander Vakrilov Telerik Corporation Senior Developer and Team Leader.
Best Practices. Contents Bad Practices Good Practices.
1 Software Maintenance and Evolution CSSE 575: Session 3, Part 1 Simplifying Conditionals Steve Chenoweth Office Phone: (812) Cell: (937)
Refactoring1 Improving the structure of existing code.
The effectiveness of refactoring based on a compatibility testing taxonomy and a dependency graph Steve Counsell and Robert Hierons, Brunel University,
Refactoring Deciding what to make a superclass or interface is difficult. Some of these refactorings are helpful. Some research items include Inheritance.
Housekeeping  SVN  Mandatory for project  Will be a spot check in the next couple of weeks to identify whether “software craftmanship” is being practiced.
1 CSC/ECE 517 Fall 2010 Lec. 3 Overview of Eclipse Lectures Lecture 2 “Lecture 0” Lecture 3 1.Overview 2.Installing and Running 3.Building and Running.
Software Engineering CS3003 Lecture 4 Code bad smells and refactoring.
Refactoring and such ● (Side note) Specialization ● Key terms ● Abstraction, state, persistence and association and their relationship to software development.
Refactoring: Code Smells. Admin Notes REGISTER FOR BLACKBOARD Watch blackboard site for updates on class as hurricane season approaches.
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.
E L EARNING E NVIRONMENT FOR S OFTWARE E NGINEERING E DUCATION (R EFACTORING A GENT ) A.Stoyanova-Doycheva University of Plovdiv г. 10th Workshop.
REFACTORINGREFACTORING. Realities Code evolves substantially during development Requirements changes 1%-4% per month on a project Current methodologies.
NJIT 1 Test Driven Development and Refactoring Larman, Chapter 21.
Module 3. Smells Between Classes Course: Refactoring.
Com S 362: Object-Oriented Analysis and Design Refactoring.
How and When to do Refactoring CSE301 University of Sunderland Harry R. Erwin, PhD.
Refactoring Conditionals Lesson Five: Conditionals.
Software Construction and Evolution - CSSE 375 Making Method Calls Simpler Shawn and Steve Below – “Be the character!” The late acting teacher Lee Strasberg.
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
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.
CSSE 375 Organizing Data – Part 2 Shawn and Steve Continue the same quiz!
Refactoring1 Improving the structure of existing code.
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.
Software Construction and Evolution - CSSE 375 Simplifying Conditionals Shawn & Steve.
CSSE 375 Organizing Data – Part 1 Shawn and Steve Q1.
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.
Catalog of Refactoring (5) Simplifying Conditional Expressions.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Catalog of Refactoring (6) Making Method Calls Simpler.
Principles and examples
Module Road Map Refactoring Why Refactoring? Examples
Overview of Eclipse Lectures
Refactoring III 27-Nov-18.
Code Smells 1.
Improving the structure of existing code
Refactoring III 25-Dec-18.
Refactoring.
Presentation transcript:

Refactoring 2

Admin Blackboard Quiz

Acknowledgements Material in this presentation was drawn from Martin Fowler, Refactoring: Improving the Design of Existing Code

Refactorings (Fowler) Add Parameter Change Bidirectional Association to Unidirectional Change Reference to Value Change Unidirectional Association to Bidirectional Change Value to Reference Collapse Hierarchy Consolidate Conditional Expression Consolidate Duplicate Conditional Fragments Convert Procedural Design to Objects Decompose Conditional Duplicate Observed Data Encapsulate Collection Encapsulate Downcast Encapsulate Field Extract Class Extract Hierarchy Extract Interface Extract Method Extract Subclass Extract Superclass Form Template Method Hide Delegate Hide Method Inline Class Inline Method

Refactorings (Fowler) Inline Temp Introduce Assertion Introduce Explaining Variable Introduce Foreign Method Introduce Local Extension Introduce Null Object Introduce Parameter Object Move Field Move Method Parameterize Method Preserve Whole Object Pull Up Constructor Body Pull Up Field Pull Up Method Push Down Field Push Down Method Remove Assignments to Parameters Remove Control Flag Remove Middle Man Remove Parameter Remove Setting Method Rename Method Replace Array with Object Replace Conditional with Polymorphism Replace Constructor with Factory Method Replace Data Value with Object Replace Delegation with Inheritance

Refactorings (Fowler) Replace Error Code with Exception Replace Exception with Test Replace Inheritance with Delegation Replace Magic Number with Symbolic Constant Replace Method with Method Object Replace Nested Conditional with Guard Clauses Replace Parameter with Explicit Methods Replace Parameter with Method Replace Record with Data Class Replace Subclass with Fields Replace Temp with Query Replace Type Code with Class Replace Type Code with State/Strategy Replace Type Code with Subclasses Self Encapsulate Field Separate Domain from Presentation Separate Query from Modifier Split Temporary Variable Substitute Algorithm Tease Apart Inheritance

Refactorings (Testing) Inline Resource Setup External Resource Make Resource Unique Reduce Data Add Assertion Explanation Introduce Equality Method

Refactorings (Astels) Make Methods Independent Replace Assert

Consolidate Conditional Expression Multiple conditionals can be extracted into method Don’t do if conditions are really independent Example BEFORE double diasabilityAmount() { if (_seniority < 2) return 0; if (_monthsDisabled > 12) return 0; if (_isPartTime) return 0; if (_isVeteran) return 50; // Calculate disability amount AFTER double diasabilityAmount() { if (isNotEligibleForDisability) return 0; if (_isVeteran) return 50; // Calculate disability amount

Duplicate Observed Data Problem: You have data stored in a GUI component and domain methods need access Solution: Copy the data into a domain object (so the methods can access it) and use an Observer to keep the two locations synchronized

Extract Class Remove a piece of a class and make it a separate class Done when class is too big to understand easily or behavior is not narrowly defined enough Indicated by having subsets of data & methods that go together, are changed together, or are dependent on each other Ask “What if I removed this? What would become useless?”

Extract Interface Define an interface to move away from a concrete implementation Allows easier use of differing databases or MockObjects

Extract Method Pull code out into a separate method when the original method is long or complex Name the new method so as to make the original method clearer Each method should have just one task extractMethod.htmlhttp:// extractMethod.html

Extract Subclass Used when a class has some behavior used for some instances and not for others Make a subclass that inherits the common functionality

Introduce Assertion Make implicit assumptions in the code explicit ntroduceAssertion.htmlhttp:// ntroduceAssertion.html

Introduce Explaining Variable Break up complex expressions into chunks with clarifying names ntroduceExplainingVariable.htmlhttp:// ntroduceExplainingVariable.html

Introduce Parameter Object Replace a group of parameters that go together with an object Makes long parameter lists shorter & easier to understand Can indicate functionality to move to new class ntroduceParameterObject.htmlhttp:// ntroduceParameterObject.html

Preserve Whole Object Send the whole object rather than long lists of values obtained from the object May increase dependency A method that uses multiple values from another class should be examined to determine if the method should be moved instead preserveWholeObject.htmlhttp:// preserveWholeObject.html

Rename Method Method names should clearly communicate the one task that the method performs If you are having trouble naming the method, it might be doing too much. Try extracting other methods first

Replace Conditional with Polymorphism Replace switch statements with polymorphic subclasses (or push case behavior down to existing subclasses) replaceConditionalWithPolymorphism. htmlhttp:// replaceConditionalWithPolymorphism. html

Replace Magic Number with Symbolic Constant Replace hard-coded literal values with constants Avoids duplication and shotgun surgery replaceMagicNumberWithSymbolicCon stant.htmlhttp:// replaceMagicNumberWithSymbolicCon stant.html

Replace Nested Conditional with Guard Clauses In some conditionals, both paths are normal behavior & the code just needs to pick one Other conditionals represent uncommon behavior Use if/else with the normal behavior paths & guard clauses with uncommon behavior replaceNestedConditionalWithGuardCl auses.htmlhttp:// replaceNestedConditionalWithGuardCl auses.html

Replace Parameter with Method A routine invokes a method just to pass the result of that method on to another method Let the 2 nd method call the first method directly (if it can) replaceParameterWithMethod.htmlhttp:// replaceParameterWithMethod.html

DeMorgan’s Law Used for simplifying boolean expressions !(a && b) => (!a) || (!b) !(a || b) => (!a) && (!b)

Further resources