Advanced Object-Oriented Design Lecture 5 Software Refactoring Part I: Introduction Bartosz Walter <Bartek. Walter@man. poznan. pl>
Motto „Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ” Martin Fowler
Agenda 1. Refactoring: ideas, motivation, examples 2. Verification of refactorings 3. Bad smells in code
More functionality!
Oh, I've found a bug. . .
We've got no time. Let's integrate. . .
Motivation for refactoring § § § High cost of maintenance § Yourdon: 80% of TCD Software decays during development Low understanding of code Design does not fit the requirements/ functionality YAGNI = You Aren't Going to Need It
Refactoring is: § § § a change made to the internal structure of software it easier to understand cheaper to to make modify changing its observable behaviour without void do. Sth() Source: W. Opdyke
Simplest example Extract Method void comp. And. Print() { // compute X // compute Y. . . // print X // print Y. . . // store X // store Y } void compute () { // compute X // compute Y print(X, Y); // store X // store Y } void print(X, Y) { // print X // print Y } § One method – one function § Allows localizing the potential bugs
Simplest example (reverted) Inline Method void compute () { X = next(X); Y = next(Y); } void comp. And. Print() {. . . X++; Y++; . . . } int next(N) { return N++; } § Removal of very short methods
Cost of refactoring Refactoring is costly because it does not add new functions to the system. The cost depends on: § the language used § support from CASE tools § the type of refactorings § number and quality of test cases Important factors: § cost of documentation update § cost of test cases update
When to do and not do refactoring? § § Three strikes and refactor When adding new functions When fixing a bug While inspecting code § § § At close deadlines Prematurely published interfaces Unstable, rubbish code Unfinished refactoring is like going into debt. You can live with. Ward Cunningham it, but it is costly.
Verification of refactorings SIMPLE HARD § Automated verification § Implemented in many IDEs § Verification requires testing § Tests need to be manually created
Simple refactorings. . . § Verification of pre-conditions § Static analysis of code void do. Sth() If before. . . . void do. Sth() Then after. . . .
. . . and hard ones § Static code analysis, preconditions § Role of unit tests void do. Sth() If before. . . . void do. Sth() Then after. . . .
Bad smells If it stinks, change it Kent Beck grandma discussing child-rearing philosophy
Duplicated Code Same or similar code appears all over the system § in same class: extract out the common bits into their own method (extract method) § in sibling classes: extract method with a shared functionality and then pull up the method to a common superclass § in unrelated classes: extract class
Long Method Same or similar code appears all over the system § Too many options, causing the method to do too many things § Not enough support from other methods, causing the method to do tasks at a lower level than it should § § Overly complicated exception lines handling the rule of one screen/twenty § extract code
Large class Same or similar code appears all over the system § No clear definition of what the class should do, resulting in it doing rather a lot of different things § Out-of-control inner classes § Numerous static and instance methods § Excessive numbers of convenience methods § Cut-and-pasted code § extract new class/subclass/interface § pull up methods/fields
Long Parameter List Method needs to much external information § replace parameter with method (receiver explicitly asks sender for data via sender getter method) § replace parameters with a member fields in a dedicated object
Divergent Change Same or related code appears all over the system Many different changes are necessary § Separate out the varying code into varying classes (extract class) that either subclass or are contained by the non-varying class § Use Visitor or Self Delegation patterns
Feature Envy Method in one class uses lots of pieces from another class § move method to the other class § use Visitor or Self Delegation patterns
Data Clumps Data that's always hanging with each other (e. g. name street zip) § Extract out a class (extract class) for the data § Related to long parameter list. § Introduce a Parameter Object § Preserve whole object
Summary § § Refactoring decreases cost of maintenance Refactoring preserves software behaviour Testing and analysis as methods of verification Code smells indicate a need for refactoring
Q&A
Скачать презентацию Advanced Object-Oriented Design Lecture 5 Software Refactoring Part
793aab9c4d0724a9508210a1002af3ed.ppt