Introduction to Refactoring

Transcription

1 Introduction to Refactoring Anders Jonsson , Daniel Blomskog , Daniel Söderholm , May 18, 2003

2 Abstract This report is written as an introduction to refactoring for those that have no knowledge of the area. It covers the basics of refactoring, a brief look at the history of refactoring and the meaning of the word refactoring. There are some examples on how different refactory-function work, what their preconditions are and what they do. It also takes a look at the use of software design patterns by refactoring to patterns. Last, but not least, it covers refactoring-tools and names a few examples of different tools available.

3 Introduction Refactoring history Refactoring code has been done since people started programming. Cleaning up code is refactoring, making small changes to make a program faster or more memory efficient is refactoring. However it is not until recently people started to discuss different techniques for it. The discussion began when Martin Fowler published his book on Refactoring 1 in which he included the first basic refactoring patterns, and the field is getting larger as imperative programming is more and more replaced by OO. This is because of the high costs involving the process of creating new software from scratch and the factor that OO-programming produces code that is easier to use. People are starting to develop special tools for refactoring and try to make the refactoring-process as automated as possible, but that is a process that is going to take time to tune to perfection. There is a section on different tools and a little explanation on the theory behind them later on. Like always when it comes to programming people think different about how things should be done. The two major directions in this matter are If it is working do not change it and Refactor everything you come across aka refactor mercilessly. Most programmers land somewhere in between these two, refactoring at the same time they are fixing small bugs. The expression refactor The expression refactoring comes from mathematics: when you factor an expression, thus getting a cleaner way of expressing a statement, but you still get the same result when using it. example: (x 1) (x + 1) = x 2 1 The leftmost expression has four terms and the rightmost has two. The leftmost has three operators while the rightmost has two. Even though the leftmost expression has more terms and operators it is easier to understand because it uses simpler operations. One also gets more information from the leftmost expression out of just looking at it, like that the roots are +1/ 1, things which are harder to see by just looking at the right one (maybe not in this case but if you have larger expressions). 1 Refactoring: Improving the Design of Existing Code

4 Refactoring code Refactoring is the process in which one takes a program and change its internal structure without changing its external behavior. The goal of the refactoring process is to make the programs internal structure better i.e. smarter design and more readable and reusable code. Refactoring has been done since people started programming, all programmers do it. example: a programmer changes the name of a function, maybe replaces some duplicate code with calls to a function, changing an interface to make it more reusable. It is typically done in small steps like the examples above and when you are done with one of those small steps you should still have a system that works and is unchanged functionality wise. Bug fixes and adding new functions should not be done during the refactoring process, instead the main goal is to keep it simple. For example, it is better to do a small change and make sure it works than do many changes and then spending hours finding out what went wrong and where. It has also been said that small changes leads to errors more times than larger changes. This is because most programmers take those small changes less seriously. This leads to less testing and less testing leads to more errors in the future. Conclusion: Do small changes and make sure that they are correct before changing anything else. Object-Oriented programming and refactoring For most people Object-Oriented programming stands for easy reusability and code that is easy to understand. Let us look at some advantages of programming in an OO-language. In most OO-languages one can use data abstraction using classes, which support encapsulation and information hiding. These are all properties that fit well for a reusable component. Then there is class inheritance which means that operations of classes can be inherited and reused by its subclasses. Another great thing about OO-programming is polymorphism. With polymorphism, methods can operate over many different types of data so that the same code can be used in many situations. On the other hand, some of the benefits of OO-languages make the refactoring process more complex due to the interrelationship between classes. As a program keep getting larger and larger the refactorings get more and more complicated and time consuming to do manually. This is why more and more tools for automating the refactoring-process are being developed. More on this in the Tools chapter. Motivations for refactoring A piece of software can be seen as a big town, it is not easy to design a perfect city on your own it takes the work of many citizens refactoring to the better all the time. One factor that highly motivates reusing already existing software is the major costs of program development. You see more and more companies buying an

5 existing system. But these systems are not always perfect for the job. There is almost always software that almost solves your own problems but they need to be restructured to fit your exact needs. You can also refactor existing designs in the cases where there is no finished software that solves your problem. Refactoring makes it easier to understand a program or design and to find reusable components. While refactoring does not change the behavior of a program, it can, and usually does, change the design, and a good design is essential for easy adaptation of software. Good design also makes it easier to add or change functionality in the future.

6 Basic refactoring Factory functions Description of a refactory function A refactory function is a transformation with some preconditions on the object that is going to be changed. The precondition is to insure that the refactory property is fullfilled so the behavior of the program is not changed. Following is a collection of examples of refactory functions, divided into seperate types of refactoring. These types are: on class, on method and on instance variable. Something to remember is that a refactoring does not change the behavior but could change the performance of the program. example: Let us take a look at adding/removing variables. Both these operations changes the amount of memory used by the program, but none of them is going to change the behavior of the program. Refactory on class This function set changes the class structure of the program and it can even change the class hierarchy. Add a class To do this a set of subclasses and a superclass is used as input. If the set of subclasses are not empty then every subclass in the set need to have a common superclass and the superclass that was given as an input need to be that class. This method inserts a empty class between the superclass and the subclasses. An easy way to change the class hierachy. See Figure 1 & 2 Figure 1: Before add/after remove

7 Figure 2: After add/before remove Rename a class This function takes a class and a new name as input and changes the name of the class. The only criteria is that it should not be any nameconflict in any way. Remove a class For indata the function takes a class and removes it. The precondition of the class is that it should be unreferenced. If the class has any subclasses all their methods and variables must be able to be removed with the refactory functions remove a method and remove an instance variable. This means that the class must be empty or be able to be emptied without changing the behavior of the program. The class hierarchy changes likes in the function add a class but in the other way around. (See figure 1 & 2) Refactory on methods This function set change a class or a set of class-methods. Add a method This function takes a class and a method name. It adds a method with that name to the class. The criteria for this operation is: If a superclass has a method with the same name it must have the same semantical meaning as the method being added. Otherwise polymorphism could change the behavior of the program. A way to move methods from a superclass to its subclasses is adding a method with the same name and same semantical meaning in every subclass then remove the method from the superclass. Rename a method This function needs a set of classes, a set of methods and the new name. The need of a set and not only one class/method is because of polymorphism. If one changes a name of a method one needs to change all polymorphs of the method. example: Let us say that you have a method named insert. You change the name of the method, overlookning the method with the same name in the superclass. This

8 will remove overloading of the insert-method in the superclass. The same is true if the method in the superclass is changed without changing the overloading method in the subclass. Both these cases change the behavior of the program, therefore all methods must be changed. Changing a name of a method in a class forces a namechange of the method in every class in the class hierarchy that has this method. Remove a method This function needs a class and the method that should be removed. The criteria in this case is that it must be unreferenced and if any superclass has a method with the same name they need to be semantically the same. Refactory on variables Changes the structure of how data is stored. Add an instance variable This function needs a class and a name. variable to the class. It adds an unreferenced instance Remove an instance variable This function needs a class and an instance variable that will to be removed from the class. The variable must be unreferenced. Rename an instance variable This function needs a class and an instance variable. The function renames and updates every use of the variable. The only precondition is that there is no name conflicts. Pullup instance variable A set of subclasses that contains the variable and their common superclass. Removes the variable from the subclasses and adds it to the superclass. The other subclasses behavior does not change because an unreferenced instance variable does not change the behavior of the class. Pushdown instance variable This function takes a superclass and an instance variable. The function removes it from the superclass and adds it to the subclasses. To hold the refactory property the variable needs to be unreferenced in the superclass. Abstract instance variable Needs a class and an instance variable. Replaces all direct use of the variable with call to get and set methods.

9 Move a instance variable Needs two classes and an instance variable. Moves the variable from one class to the other and updates the references to the variable. It must be a one to one relationship between the classes. So that there always will be a variable and so that no more than one object makes use of the variable. Refactoring to patterns Flexible code vs. Productivity Patterns are a cornerstone of object-oriented design and can be used to solve many (if not all) of the problems one may encounter while making the design for a project. However, if patterns are over-used, your code becomes more flexible than it has to be. It may be a good idea to accommodate to the needs of tomorrow, but on the other hand one can never be sure of what those needs are. This kind of over-engineering takes time and, in a commercial production, time is money. Usually, that kind of over-engineered code never gets changed (because you might still have use for it, right?), and that means that you (and your fellow programmers, especially new members of the team) will have a larger and more complicated code base to operate within. Making use of design pattern takes you far on the road to become a good programmer in the object-oriented field, but you must also know when it s simply a waste of time to do so. Keeping a steady pace While being careful not to over-engineer, one must also make sure that one does not under-engineer the project. Under-engineering is far more common than over-engineering and it s more dangerous to the project. Under-engineering usually happens when we focus on adding more and more to a system without improving it s design along the way. When the code is working you simply move along to the next part without improving the part you just wrote. This usually leads to the fast, slow, slower rhythm of development, which goes like this 1. The first release goes fast (but with some junky code in the trunk). 2. The second release takes time since you have to deal with some of the junky code, and in doing so you write even more junky code. 3. Future releases goes even slower since there is more junky code to deal with. People will probably start to lose interest in the product by now. Under-engineering can be eliminated by applying Merciless Refactoring. Merciless Refactoring is a practice of extreme programming and simply means that you should refactor as soon as you find something you CAN refactor. When you find two methods that look the same, you refactor the code to combine them. When you find two objects with common functionality, you refactor to make there be just one [ This

10 will result in a design that is upgraded continuously. The trick to merciless refactoring is to not schedule time to make small design improvements, but to make them whenever your code needs them. [Joshua Kerievsky] Motivations for RtP The motivations for refactoring to patterns are basically the same as for any other refactoring. To reduce duplication, to simplify code, to add greater flexibility and to make the code more understandable. Even though non-pattern-based refactorings can, and should, be used in most cases, you might run across places where patterns can help improve your design greatly. In those cases you should refactor to patterns, while being careful not to make overly flexible or sophisticated solutions. Knowing WHY and WHEN to use Refactoring to Patterns is more important than knowing HOW to do it. Refactoring-tools Even though refactoring can easily be used manually, in larger projects it can easily become a chore. Fortunately, there are several tools that can be used to make the process faster. A good refactoring tool should include many refactorings while being careful not to make too many changes. It should also inform the user of the motivation and consequences of the refactorings used. None of these tools include Refactoring to Patterns since that is a very difficult thing to do and the field is still relatively unknown. According to the team at the refactoring process with the help of refactoring-tools can be described like this: Refactoring is only practical with tools that automate the labor-intensive activities of streamlining and reorganizing code bases. During the research, probing and understanding phase, the work is in identifying and grasping the code architecture. This early stage involves heavy use of special query and search tools that quickly expose the functional hierarchy of methods and program elements. In the next phase of moving and reorganizing code fragments, the developer uses their code editor or IDE in conjunction with automatic transformation tools. Variables, file names, and other references must be globally converted or changed to maintain code integrity. Dependency checking tools help insure code integrity and readiness for build. The testing phase is a natural extension of refactoring, and during the frequent refactoring-testing cycles tight interaction between the editor/ide and the refactoring tools are required for maximum productivity. Finally, checking code metrics is done with special tools to detect unused methods, overcomplex constructs, and hot spots in modules. Java is by far the most represented language in the world of refactoring-tools. This is because Java is more restricted than for example C or C++ which makes it easier to do major refactorings without causing errors.

11 Crossing Refactorings rubicon Martin Fowler has written an article about the tasks that a Refactoring-tool should be able to complete to be a real asset in the process of refactoring. The article is something that should be read and considered by anyone that has plans on making a refactoring-tool. Tools, tools, tools... Following are some examples of common refactoring-tools for a few programming languages. Most of these tools are free, but some are commercial projects. The quotes are from their respective web-pages Smalltalk Refactoring Browser The Smalltalk Refactoring Browser was the first refactoring-tool to see the light of day, and it s still widely used in the Smalltalk community. Besides IBM Smalltalk it supports VisualWorks and VisualWorks/ENVY. It s refactoring support is described to Automatically perform some behavior preserving transformations such as abstracting references to an instance variable. Many of the refactorings are from Bill Opdyke s thesis.. It also includes functions as Lint, a function that automatically looks for over 60 types of common smalltalk bugs in your program. Java XRefactory XRefactory is a tool for C and Java that provides code completion, source browsing and refactoring. It is available for both Unix and Windows and provides full integration with Emacs, XEmacs and Jedit. It claims to be the world s first tool Crossing Refactoring s Rubicon. RefactorIT RefactorIT is a plugin for Forte, JDeveloper, JBuilder and NetBeans. It can also be used as a stand-alone tool. It boasts as being the first product to fully cover every part of the refactoring cycle. jfactor jfactor was the second tool Crossing Refactoring s Rubicon and according to it s website it is a product family that provides powerful new code refactoring

12 tools to professional Java integrated development environments (IDE). It provides many refactorings and claims to improve code design quickly and safely as well as to increase developer productivity. IntelliJ IDEA A full-featured Java IDE with refactoring support. It claims to be the most intelligent Java IDE around.. It includes many refactorings and more seems to be added for every release. CodeGuide CodeGuide offers advanced refactoring capabilities. It can rename methods, fields, variables, labels, classes or packages and automatically update all references throughout the project. It can move classes and packages and update all references. CodeGuide will check for potential problems prior to refactoring to make the refactorings safe. There are a couple of intelligent coding tools that will help you perform common tasks such as Javadoc stub insertion, setter & getter creation and import organization. C/C++ CppRefactory CppRefactory is a project in the makings. The finished tool will, according to the webpage, be an application that allows developers to refactor their C++ code. Its goal is to make the refactoring of C++ code as efficient and painless as possible. Alejandra Garrido garrido/ Alejandra is currently working on a refactoring-tool for C, with focus on preprocessor directives. XRefactory As mentioned above, XRefactory supports both Java and C. C# C# Refactoring Tool Fully integrated add-in for Microsoft Visual Studio.NET. It supports many refactorings as well as undo/redo.

13 C# Refactory According to the website it is a revolutionary new tool which enhances Microsoft s Visual Studio.NET IDE. It includes many refactorings and adds a refactoring item to the edit menu in Visual Studio. doteasy doteasy is a Visual Studio.Net Add-in that evaluates C# source code and performs advices in order to improve software quality. It is not exactly a refactoring-tool yet, but it still deserves to be mentioned as it seems to be a promising tool. Visual Basic Project Analyzer Project Analyzer is a complete code review and quality control tool for Visual Basic. It s not exactly a refactoring-tool, but it includes lots of related functionality. Python Bicycle Repair Man The Bicycle Repair Man project is an attempt to create a refactoring browser for python, using Extreme Programming techniques to deliver high quality functionality in as short a time frame as possible. At least it has the best name around. Perl PREFACE: The Perl REFACtoring Engine The Perl REFACtoring Engine is a project in the works. There has not yet been any releases and it s status is unknown. The project has most likely been abandoned, but you might still want to check it out once in a while. Haskell Apparently, there are plans for Haskell refactoring-tools, but none seems to be in the makings at this moment.

14 Related areas and work As you can see refactoring is highly related to many other areas of programming. For example Extreme Programming solely depends on refactoring since you develop a working product as fast as possible and then refactor the code to make it better design wise and more reusable. Refactoring does not depend on XP tough. Restructure and reworking are also related areas. If you want to learn more about refactoring you might want to read the works of Martin Fowler, William F. Opdyke and Donald Roberts, and if refactoring to pattern seems interesting you should check out the work of Joshua Kerievsky.

15 Conclusion Refactoring is a technique that most programmers use without even knowing it. However, much can be gained by learning more about the field in general, as well as good ways to go about it. By use of refactoring you can quickly become a better programmer as you gain more knowledge about good designs and solutions. You will also learn how to reuse already existing design and components better, whether they are of your own devising or not. By using some of the refactoring-functions mentioned in this report, bad code could be improved by changing name of variable, methods and class. You can also use refactoring for upgrades by adding classes, methods and variables. You can also increase the performace through factory-methods. The chapter Refactoring to patterns gives some well needed words of caution on the use of design patterns as well as advices on how and when to use patterns in your projects. The use of refactoring-tools can simplify the refactoring-process as well as make it more secure. On the other hand you, as a programmer, should make sure that you understand what the tool is doing, and why. The tools are a great help, but you should never solely depend on them.

16 Discussion When a project grows it is important to have a code that is easy to read. Changing of standards or updating existing standard could demand a hard work. Through refactoring tools could this type of work done easily instead of going through 1000 s of lines of code replaceing names. By refactoring you can change the way the code works even in runtime without changing behavior. This could be used to make optimizations for diffrent runtime-situations depending on memory-size, CPU-speed etc. We, the authors of this report, believe that refactoring as a field will grow to become a cornerstone of the programming world. In fact, it already is a cornerstone, since nearly every programmer use some sort of refactoring whether they know it or not. However the field will become more discussed and refined.

17 References & sources Martin Fowler s website on refactoring [ Refactoring to Patterns [Joshua Kerievsky, Refactoring on the Wiki [ Practical Analysis for Refactoring [Donald Roberts, droberts/thesis.pdf] Refactoring object-oriented frameworks [William Opdyke, ftp://st.cs.uiuc.edu/pub/papers/refactoring/opdyke-thesis.ps.z] And, of course, the websites mentioned in the Refactoring-tools section. 16