Gregor Gisler-Merz 23.07.2003 1 BrownBag Session Refactoring.

Slides:



Advertisements
Similar presentations
12-Dec-14 Refactoring IV. Previously discussed bad smells Duplicated code — and other forms of redundancy Long method — use short methods that delegate.
Advertisements

Clean code. Motivation Total cost = the cost of developing + maintenance cost Maintenance cost = cost of understanding + cost of changes + cost of testing.
© 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
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
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)
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.
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
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.
What is Refactoring? CSE301 University of Sunderland Harry R. Erwin, PhD.
Advanced Programing practices
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.
Sadegh Aliakbary Sharif University of Technology Spring 2012.
LECTURE 38: REFACTORING CSC 395 – Software Engineering.
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.
Refactoring Improving the structure of existing code Refactoring1.
17-Oct-15 Refactoring. 2 Refactoring is: restructuring (rearranging) code......in a series of small, semantics-preserving transformations (i.e. the code.
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.
Refactoring1 Improving the structure of existing code.
Alcatel-Lucent CDC Workshop, Coaching & Knowledge Transfer Coding.
Introduction to Refactoring Jim Cooper Falafel Software.
Informatics 122 Software Design II
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 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.
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.
Refactoring II Dealing with Polymorphism. Switch in Rental Switches on Movie! class Rental … public double getCharge() { double result = 0; switch (getMovie().getPriceCode()){
Module 3. Smells Between Classes Course: Refactoring.
1 Software Maintenance and Evolution CSSE 575: Session 2, Part 1 Refactoring Principles Steve Chenoweth Office Phone: (812) Cell: (937)
Software Construction and Evolution - CSSE 375 Making Method Calls Simpler Shawn and Steve Below – “Be the character!” The late acting teacher Lee Strasberg.
1 Software Maintenance and Evolution CSSE 575: Session 3, Part 3 Dealing with Generalization Steve Chenoweth Office Phone: (812) Cell: (937)
Refactoring Mehdi Einali Advanced Programming in Java 1.
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.
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 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.
Principles and examples
Steve Chenoweth Office Phone: (812) Cell: (937)
Module Road Map Refactoring Why Refactoring? Examples
Steve Chenoweth Office Phone: (812) Cell: (937)
A Very Common Series of Techniques
Refactoring and Code Smells
بازآرایی برنامه Code Refactoring
Overview of Eclipse Lectures
Code Smells 1.
Improving the structure of existing code
Refactoring and Code Smells
Advanced Programming Behnam Hatami Fall 2017.
Refactoring.
Refactoring and Code Smells
Advanced Programing practices
Refactoring.
Refactoring and Code Smells
Presentation transcript:

Gregor Gisler-Merz BrownBag Session Refactoring

Gregor Gisler-Merz Content: Refactoring – The big picture Definition of refactoring A sample General rules of thumb Refactoring categories according to Fowler Where do I find a catalog for common refactorings? What indicators are there for a refactoring? Bad smells (1-4) When is the right time for a refactoring? Bigger refactorings Architectural Smells: indicators for bigger refactorings! References

Gregor Gisler-Merz Refactoring – The big picture: Everybody can write machine interpretable code but only good programmers can write code understandable by human beings! Emergent Design - versus – BigDesignUpfront. Refactoring is the main tool with an Emergent Design approach. Refactorings can be induced by technological change (introduction of new technology) or due to new requirements. What is the difference between a refactoring and a redesign? –Refactoring is ongoing over the livecycle –Redesign and Reengineering tasks are big and costly and indicate a lack of refactoring during the product livecycle Refactorings are necessary especially in agile environments where the release cycles are short and the involved parties know that the requirements change within the cycles.

Gregor Gisler-Merz Definition of Refactoring : Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

Gregor Gisler-Merz A sample: Situation before refactoring: –No OO design –Complete logic in Customer.statement() –Not possible to reuse functionality if adding a html report –A lot of case and if statements due to the lack of inheritance and polymorphism Situation after refactoring: –After a series of refactorings the classes and its methods are small and good readable –Extensible code –Things are done in the appropriate objects Initial Class diagram movie sample Class diagram movie sample after refactoring

Gregor Gisler-Merz General rules of thumb If you have to add something to your program and the structure does not allow a plain-vanilla implementation refactor the code so the change can be done easily afterwards. Upfront refactoring ensure that a profound set of test cases is available. Refactor the code in small overseeable steps. Possible bugs can then easily be found. Kent Beck's metaphor of the two hats: –Add functionality -> Don't change existing code just add new features and tests –Refactoring -> no new functionality, usually no new tests Don Roberts: If you do a thing for the first time then do it. If you do something similar the second time you hesitate but do it once again. If you do it for the third time: refactor it!

Gregor Gisler-Merz Refactoring categories according to Fowler: Composing methods: Extract Method, Inline Temp, Replace Temp with Query Moving Features Between Objects: Move Method, Extract Class, Remove Middle Man Organizing Data: Self Encapsulate Field, Replace Type Code with Class, Replace Array with Object Simplifying Conditional Expressions: Introduce Null Object, Decompose Conditional Making Method Calls Simpler: Rename Method, Add Parameter, Replace Error Code with Exception Dealing with Generalization: Pull Up Field, Extract Interface, Form Template Method

Gregor Gisler-Merz Where do I find a catalog for common refactorings?: 72 Refactorings are described on Martin Fowler's Page –Add ParameterAdd Parameter –Change Bidirectional Association to UnidirectionalChange Bidirectional Association to Unidirectional –Change Reference to ValueChange Reference to Value –Change Unidirectional Association to BidirectionalChange Unidirectional Association to Bidirectional –Change Value to ReferenceChange Value to Reference –Collapse HierarchyCollapse Hierarchy –Consolidate Conditional ExpressionConsolidate Conditional Expression –Consolidate Duplicate Conditional FragmentsConsolidate Duplicate Conditional Fragments –Convert Dynamic to Static Construction by Gerard M. DavisonConvert Dynamic to Static Construction –Convert Static to Dynamic Construction by Gerard M. DavisonConvert Static to Dynamic Construction –Decompose ConditionalDecompose Conditional –Duplicate Observed DataDuplicate Observed Data –Eliminate Inter-Entity Bean Communication (Link Only)Eliminate Inter-Entity Bean Communication –Encapsulate CollectionEncapsulate Collection –Encapsulate Downcast..... see in the Internet for the restEncapsulate Downcast

Gregor Gisler-Merz What indicators are there for a refactoring? Bad smells (1) : 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 Data clumps: groups of data appearing together in the fields of classes, parameters to methods, etc. e.g., int x, int y, int z -> move these groups into their own class. One can use Extract Class and Introduce Parameter Example: group (start: Date, end: Date) into (aRange: RangeDate) Primitive obsession: using the built-in types of the language too much reluctance to use small objects for small tasks e.g., zip code string -> use objects for individual data values. One can use Replace Data Value with Object

Gregor Gisler-Merz Bad smells continued (2) Switch statements: consider using polymorphism instead e.g., conditionals on type codes defined in other classes. One can use Extract Method (on the switch), Move Method, Replace Type Code, and Replace Conditional with Polymorphism Speculative generality: I think we might need this someday. e.g., abstract classes without a real purpose e.g., unused parameters. One can use Collapse Hierarchy and Remove Parameter Message chains: long chains of navigation to get to an object e.g., client object talks to server object that delegates to another object that the client object must also know about. One can use Hide Delegate

Gregor Gisler-Merz Bad smells continued (3) Middle man: a class that delegates many methods to another class can use Remove Middle Man or Replace Delegation with Inheritance. Attention could also be a legitimate adapter Don t stand so close: two classes that depend too much on each other, with lots of bidirectional communication. Separate the two classes. One can use Move Method, Move Field, and Extract Class (factor out commonality) Alternative classes with different interfaces: methods that do the same thing but have different signatures e.g., put() versus add(). One can use Rename Method

Gregor Gisler-Merz Bad smells continued (4) Refused bequest: when a subclass inherits something that is not needed when a superclass does not contain truly common state/behaviour. One can use Push Down Method and Push Down Field or one can use Replace Inheritance with Delegation (e.g., Square versus Rectangle) Comments: often deodorant for bad smelling code. Refactor code so that the comment becomes extraneous

Gregor Gisler-Merz When is the right time for a refactoring? Whenever you see something that isn't solved adequately Don Roberts "Rule of three" "Once and only once principle" Before adding new functionality While fixing errors During and after Code Reviews If in doubt discuss it with your peers!

Gregor Gisler-Merz Bigger refactorings Big refactorings denote larger refactoring tasks like changing a large inheritance hierarchy Reasons implying bigger refactorings: – Developer missed smaller refactorings (cumulation) – Slow creep in of architectural smells – New features – technology changes (would be low on good software) Differentiation between: –Elementary Refactoring -> Fowler 99 –Big Refactorings -> Rule of thumb: Effort more than one day, affect the whole project team and cannot be implemented by elementary safe refactorings. There are additional unsafe modifications needed

Gregor Gisler-Merz Architectural Smells: indicators for bigger refactorings! Static relation usage (dynamic/runtime relation usage) –Unused classes –Tree like usage –Static cycles Smells in the inheritance hierarchy –InstanceOf calls and missing usage of polymorphism –List like inheritance hierarchies – Speculative generality smell –Subclasses redefine no methods –Parallel inheritance hierarchies –Inheritance hierarchies that are too deep Smells in packages –Unused packages, cycles, packages too small, packages too big –No appropriate hierarchy (deep versus shallow)

Gregor Gisler-Merz Architectural Smells (2) Smell in subsystems –No subsystems, too little subsystems, too large subsystems (more than 100 packages) –Too many subsystems –By-pass subsystem API –Cycles in subsystems Smells in layers –No layering –Upward references (cycles between the layers) –Breach of layers –Too many layers –References between vertical separated layers

Gregor Gisler-Merz References : Fowlers refactoring homepage: Refactorings to patterns: Bad smells homepage: Movie refactoring sample: es/Refactoring-Example.pdf es/Refactoring-Example.pdf Refactoring M. Fowler et al. Addison-Wesley, 1999