© 2010 Shawn A. Bohner Software Construction and Evolution - CSSE 375 Even more Bad Smells in Code Shawn & Steve Q1 Shawn & Steve Hint 

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.
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.
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.
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
12-Jul-15 Refactoring. 2 Refactoring is: restructuring (rearranging) code......in a series of small, semantics-preserving transformations (i.e. the code.
Refactoring to Patterns Ravindra Chilaka Extreme Programming Seminar XP 2004 b.
Leiden University. The university to discover. Leiden University. The university to discover. Leiden University. The university to discover. Software Engineering.
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.
Software Refactoring Part I: Introduction Bartosz Walter Advanced Object-Oriented Design Lecture 5.
1 Software Maintenance and Evolution CSSE 575: Session 1, Part 3 Bad Smells in Code - 1 Steve Chenoweth Office Phone: (812) Cell: (937)
LECTURE 38: REFACTORING CSC 395 – Software Engineering.
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.
Chapter 7: Bad Code Smells Omar Meqdadi SE 3860 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Refactoring (continued) Source: "Refactoring: Improving the Design of Existing Code", Martin Fowler.
When and How to Refactor? Refactoring Patterns Alexander Vakrilov Telerik Corporation Senior Developer and Team Leader.
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.
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.
Software Testing and Maintenance Agile Software Development Jeff Offutt SWE 437 George Mason University 2008 Based on Agile Estimating and Planning, Cohn,
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)
C++ Inheritance Data Structures & OO Development I 1 Computer Science Dept Va Tech June 2007 © McQuain Generalization versus Abstraction Abstraction:simplify.
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.
CSC 4700 Software Engineering
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.
CSSE 375 Organizing Data – Part 1 Shawn and Steve Q1.
Software Construction and Evolution - CSSE 375 Dealing with Generalization Steve and Shawn Left – In the 1990 movie “The Freshman,” Matthew Broderick,
Module 9. Dealing with Generalization Course: Refactoring.
10-Jun-16.  Refactoring is: ◦ restructuring (rearranging) code... ◦...in a series of small, semantics-preserving transformations (i.e. the code keeps.
A (Very) Simple Example Consolidate duplicate conditional fragments if (isSpecialDeal()) { total = price * 0.95; send (); } else { total = price * 0.98;
Principles and examples
Steve Chenoweth Office Phone: (812) Cell: (937)
Steve Chenoweth Office Phone: (812) Cell: (937)
Inheritance and Polymorphism
Steve Chenoweth Office Phone: (812) Cell: (937)
Refactoring and Code Smells
Software Construction and Evolution - CSSE 375 Composing Methods
بازآرایی برنامه Code Refactoring
Code Smells 1.
Improving the structure of existing code
Refactoring and Code Smells
Refactoring Types Blake Duncan.
Refactoring.
Refactoring and Code Smells
Refactoring.
Refactoring and Code Smells
Presentation transcript:

© 2010 Shawn A. Bohner Software Construction and Evolution - CSSE 375 Even more Bad Smells in Code Shawn & Steve Q1 Shawn & Steve Hint 

2 Feathers’ approach – Ch 21, for example  He approaches “bad smells” from a higher level: l Instead of just “what’s wrong with a code snippet,” more like, l “What’s making life difficult for me in coding this system?” l Fowler does this, too, some of the time. l Feathers’ Ch 21 is ~ Folwer’s “Shotgun surgery.” l Let’s look at this one, as an example… 2

3 Feathers’ Ch 21, cntd  Feathers recommends:  When you see code duplication – l Step back and consider the full scope of it. l If you combined it, what would the resulting code look like?  Then start small: l See if you can remove small parts of the duplication. l That will test your larger idea about this!  There may be good alternatives! 3 Q12 !

4 4 Back to Fowler: Refactoring Indicators: 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  Lazy Class  Parallel Inheritance Hierarchies  Speculative Generality  Temporary Field  Message Chains  Middle Man  Inappropriate Intimacy  Incomplete Library Class  Data Class  Refused Bequest  Alternative Classes w/ varied interfaces  Comments Today! 

5 Parallel Inheritance Hierarchies  Situation: Every time a subclass of one class is made, another subclass must also be made l Special case of Shotgun Surgery  Solution: l General Strategy is to eliminate the duplication to ensure that instances of one hierarch refer to instances of the other (Move Method, Move Field) Q10 (!) 

6 Speculative Generality  Situation: Presence of hooks and special cases for things that are not required, but may have been anticipated. l Extra classes and features add to complexity l Spotted by when only users are test cases  Solution: Remove unused classes and methods. If you really do need it later, you can add it back in. (Collapse hierarchy, inline class, remove parameter) 6 Q2 

7 Message Chains  Situation: Client asks for a sub-object, that asks for a sub-object, … l Multi-layer “drill down” may result in sub-sub- sub-objects being passed back to requesting client  Solution: Rethink abstraction and examine why deeply nested subpart is surfacing l Why is the subpart so simple that it’s useful far from home? l Use Hide Delegate to resurface objects and remove unnecessary indirections 7 Q3 

8 Middle Man  Situation: Too many levels of indirection! l If too many of a class’s methods beg services of delegate sub- objects, the basic abstraction is probably compromised  Solution: Remove unnecessary levels of indirection using Remove Middle Man or Replace Delegation with Inheritance. 8 Q4 

9 Class Exercise: Improved class Animal { final int MAMMAL = 0, BIRD = 1, REPTILE = 2; int myKind; // set in constructor... String getSkin() { switch (myKind) { case MAMMAL: return "hair"; case BIRD: return "feathers"; case REPTILE: return "scales"; default: return "integument"; } } }

10 Class Exercise: Improved  class Animal { String getSkin() { return "integument"; } } class Mammal extends Animal { String getSkin() { return "hair"; } } class Bird extends Animal { String getSkin() { return "feathers"; } } class Reptile extends Animal { String getSkin() { return "scales"; } }

11 How is this an improvement?  Adding a new animal type, such as Amphibian, does not require revising and recompiling existing code  Mammals, birds, and reptiles are likely to differ in other ways, and we’ve already separated them out (so we won’t need more switch statements)  We’ve gotten rid of the flags we needed to tell one kind of animal from another  Basically, we’re now using Objects the way they were meant to be used

12 Inappropriate Intimacy  Situation: Sharing of secrets between classes, especially outside the sanctioned bounds of inheritance l e.g., public variables, indiscriminate definitions of get/set methods  Solution: l Rethink basic abstraction and introduce appropriate use of get/set methods. Merge classes when intimacy warranted. (Move/Extract Method/Field, Change Bidirectional Association to Unidirectional, Hide Delegate) Q5 

13  Situation: Classes/methods seem to implement the same or similar abstraction, yet are otherwise unrelated l Not against overloading, just haphazard design  Solution: l Move the classes “closer” together. Find a common interface. Find a common subpart and remove it. (Extract [Super]Class, Move Method, Rename Method) Alternative Classes with Different Interfaces 

14 Data Class  Situation: Class consists of (simple) data fields and simple accessor/mutator methods only l Only dumb data holders l Often, you find clients using only get/set methods  Solution: l Examine client usage patterns and abstract some commonalities of usage into methods and move some behavior into data class. (Encapsulate Field/Collection, Remove Setting Method, Extract/Move Method) Q6 

15 Refused Bequest  Situation: Subclass inherits methods/data, but doesn’t seem to use some of them l Fowler says this is not as bad a smell as others l 9 times out of 10, this smell is not worth cleaning l Address it when there is confusion or problems  Solution: l Create a new sibling class and push all the unused methods into the sibling – this way abstract parent contains commonality. Then use delegation (Push down Method/Field, Replace Inheritance with Delegation) Q7 

16 Comments  Situation: Long comments are often a sign of opaque, complicated, inscrutable code l If comments are not simply rationale, consider restructuring code to be more self-evident  Solution: l Make methods short and use long identifiers. Ensure comments largely document rationale. (Extract Method, Rename Method) Q8 

17 Temporary Field  Situation: An object in which an instance variable is set only in certain circumstances l Such code is difficult to understand since you expect a class to need all it’s variables  Solution: l Create a legitimate home for the orphan variables (Extract Class) l Put all the code that concerns the variable into a component and eliminate conditional code (Introduce Null Object) 

18 Incomplete Library Class  Situation: Library class doesn’t have the functions that you need and it is difficult to modify for your purpose l Reuse touted as valuable – reuse ill-designed is troublesome…  Solution: l Special purpose tools to make the class “usable” by introducing foreign methods and extension (Introduce Foreign Method, Introduce Local Extension) Q9 