Refactoring Jan 13 2019 Refactoring Refactoring is Refactoring is not just any old restructuring restructuring rearranging code in a series of small semantics preserving transformations i e the code keeps working in order to make the code easier to maintain and modify You need to keep the code working You need small steps that preserve semantics You need to have unit tests to prove the code works There are numerous well known refactoring techniques You should be at least somewhat familiar with these before inventing your own 2 When to refactor You should refactor Any time that you see a better way to do things You can do so without breaking the code Better means making the code easier to understand and to modify in the future Unit tests are essential for this You should not refactor Stable code code that won t ever need to change Someone else s code Unless you ve inherited it and now it s yours 3 Design vs coding Design is the process of determining in detail what the finished product will be and how it will be put together Coding is following the plan In traditional engineering building bridges design is perhaps 15 of the total effort In software engineering design is 85 90 of the total effort By comparison coding is cheap 4 The refactoring environment Traditional software engineering is modeled after traditional engineering practices design first then code Assumptions Agile software engineering is based on different assumptions The desired end product can be determined in advance Workers of a given type plumbers electricians etc are interchangeable Requirements and therefore design change as users become acquainted with the software Programmers are professionals with varying skills and knowledge Programmers are in the best position for making design decisions Refactoring is fundamental to agile programming Refactoring is sometimes necessary in a traditional process when the design is found to be flawed 5 A personal view In my opinion Design because it is a lot more creative than simple coding is also a lot more fun Most small to medium sized projects could benefit from an agile programming approach Admittedly more fun is not necessarily better but it does help you retain good programmers We don t yet know about large projects Most programming methodologies attempt to turn everyone into a mediocre programmer Sadly this is probably an improvement in general These methodologies work less well when you have some very good programmers 6 Back to refactoring When should you refactor Any time you find that you can improve the design of existing code You detect a bad smell an indication that something is wrong in the code When can you refactor You should be in a supportive environment agile programming team or doing your own work You should have an adequate set of unit tests 7 Example 1 switch statements switch statements are very rare in properly designed object oriented code Therefore a switch statement is a simple and easily detected bad smell Of course not all uses of switch are bad A switch statement should not be used to distinguish between various kinds of object There are several well defined refactorings for this case The simplest is the creation of subclasses 8 Example 1 continued 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 9 Example 1 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 10 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 11 JUnit tests As we refactor we need to run JUnit tests to ensure that we haven t introduced errors public void testGetSkin assertEquals hair myMammal getSkin assertEquals feathers myBird getSkin assertEquals scales myReptile getSkin assertEquals integument myAnimal getSkin This should work equally well with either implementation The setUp method of the test fixture may need to be modified 12 Bad Smell Examples You should refactor any time you detect a bad smell in the code Examples of bad smells include Duplicate Code Long Methods Large Classes Long Parameter Lists Multi location code changes Feature Envy Data Clumps Primitive Obsession We will discuss most or all of these later 13 Eclipse refactorings Eclipse can perform several refactorings for you Rename just about anything Change method signature Move class to another package Pull up into a superclass Push down into subclasses Extract interface Generalize types Use supertype where possible Infer generic type arguments Inline method call Extract method Extract local variable Extract constant Introduce parameter Introduce factory Convert local variable to field Encapsulate field 14 The End 15
View Full Document
Unlocking...