pertemuan 12 refactoring mata kuliah: t0144 – advanced topics in software engineering tahun: 2010

Pertemuan 12Refactoring

Mata kuliah : T0144 – Advanced Topics in Software EngineeringTahun : 2010

3

Learning Outcomes

Pada akhir pertemuan ini, diharapkan :Mahasiswa dapat menerapkan prinsip prinsip Refactoring dalam software development

4

Outline Material• Refactorings Definition• Why should you refactor?• When should you refactor?• “Code Smells”• Partial list of refactorings suggestion for common code smells

What is Refactoring?“A change made to the internal structure of software to make it

easier to understand and cheaper to modify without changing its observable behavior”

(Martin Fowler)

What is Refactoring? (2)• “A change to the system that leaves its behavior unchanged,

but enhances some nonfunctional quality – simplicity, flexibility, understandability, performance”

(Kent Beck)

Why should you refactor?• Refactoring Improves the Design of Software

– Without refactoring, the design of the program will decay. As people change code—changes to realize short-term goals or changes made without a full comprehension of the design of the code—the code loses its structure.

– Poorly designed code usually takes more code to do the same things, often because the code quite literally does the same thing in several places. Thus an important aspect of improving design is to eliminate duplicate code. By eliminating the duplicates, you ensure that the code says everything once and only once, which is the essence of good design.

Why should you refactor?• Refactoring Makes Software Easier to Understand

– Refactoring helps you to make your code more readable. When refactoring you have code that works but is not ideally structured. A little time spent refactoring can make the code better communicate its purpose.

• Refactoring Helps You Find Bugs• Refactoring Helps You Program Faster

When should you refactor?• The Rule of Three

– The first time you do something, you just do it. – The second time you do something similar, you wince at the duplication,

but you do the duplicate thing anyway. – The third time you do something similar, you refactor.

• Refactor When You Add Function• Refactor When You Need to Fix a Bug• Refactor as You do a Code Review

“Code Smells”• Indicators that something may be wrong in the code• Can occur both in production code and test code• Needs “deodorant” as soon as possible

List of “Code Smells”• Alternative Classes with Different

Interfaces• Comments• Data Class• Data Clumps• Divergent Change• Duplicated Code• Feature Envy• Inappropriate Intimacy• Incomplete Library Class• Large Class• Lazy Class

• Long Method• Long Parameter List• Message Chains• Middle Man• Parallel Inheritance Hierarchies• Primitive Obsession• Refused Bequest• Shotgun Surgery• Speculative Generality• Switch Statements• Temporary Field

Example: Comments• Often used as deodorant for other smells• Not necessarily bad in and of themselves but may indicate areas

where the code is not as clear as it could be• Refactorings

– Extract Method– Introduce Assertion

Example: Duplicated Code• Code repeated in multiple places• Refactorings

– Extract Method– Extract Class– Pull Up Method– Form Template Method

Example: Data Class• A class whose only purpose is holding data• Class has instance variables, getters, and setters• Refactorings

– Move Method– Encapsulate Field– Encapsulate Collection

Example: Data Clumps• Sets of variables usually passed together in multiple places• Refactorings

– Extract Class– Introduce Parameter Object– Preserve Whole Object

Example: Inappropriate Intimacy• Classes using too many things that should be private in other

classes• Refactorings

– Move Method– Move Field– Change Bidirectional Association to Unidirectional– Replace Inheritance with Delegation– Hide Delegate

Example: Large Class• A class with too many instance variables or too much code• Refactorings

– Extract Class– Extract Subclass– Extract Interface– Replace Data Value with Object

Example: Lazy Class• A class that isn’t doing enough work to justify its maintenance• Refactorings

– Inline Class– Collapse Hierarchy

Example: Long Method• Methods with many statements, loops, or variables• Refactorings

– Extract Method– Replace Temp with Query– Replace Method with Method Object– Decompose Conditional

Example: Middle Man• One class simply delegates many of its requests to another class• Refactorings

– Hide Middle Man– Inline Method– Replace Delegation with Inheritance

Etc, etc• Read up!

22

References• Refactoring: Improving the Design of Existing Code

Martin FowlerAddison-Wesley

• The Pragmatic Programmer: From Journeyman to MasterAndrew Hunt, David ThomasAddison-Wesley Professional (October 30, 1999)

• Code Complete 2: A Practical Handbook of Software ConstructionSteve McConnellMicrosoft Press; 2nd edition (June 9, 2004)

• Smells to Refactoringshttp://wiki.java.net/bin/view/People/SmellsToRefactorings