Document 9654319

Download Report

Transcript Document 9654319

Mata kuliah
Tahun
: T0144 – Advanced Topics in Software Engineering
: 2010
Pertemuan 12
Refactoring
Learning Outcomes
Pada akhir pertemuan ini, diharapkan :
Mahasiswa dapat menerapkan prinsip prinsip Refactoring dalam
software development
3
Outline Material
•
•
•
•
•
Refactorings Definition
Why should you refactor?
When should you refactor?
“Code Smells”
Partial list of refactorings suggestion for common code smells
4
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!
References
•
•
•
•
Refactoring: Improving the Design of Existing Code
Martin Fowler
Addison-Wesley
The Pragmatic Programmer: From Journeyman to Master
Andrew Hunt, David Thomas
Addison-Wesley Professional (October 30, 1999)
Code Complete 2: A Practical Handbook of Software Construction
Steve McConnell
Microsoft Press; 2nd edition (June 9, 2004)
Smells to Refactorings
http://wiki.java.net/bin/view/People/SmellsToRefactorings
22