Book Image

Refactoring with Microsoft Visual Studio 2010

By : Peter Ritchie
Book Image

Refactoring with Microsoft Visual Studio 2010

By: Peter Ritchie

Overview of this book

Changes to design are an everyday task for many people involved in a software project. Refactoring recognizes this reality and systematizes the distinct process of modifying design and structure without affecting the external behavior of the system. As you consider the benefits of refactoring, you will need this complete guide to steer you through the process of refactoring your code for optimum results.This book will show you how to make your code base more maintainable by detailing various refactorings. Visual Studio includes some basic refactorings that can be used independently or in conjunction to make complex refactorings easier and more approachable. This book will discuss large-scale code management, which typically calls for refactoring. To do this, we will use enterprise editions of Visual Studio, which incorporate features like Application Performance Explorer and Visual Studio Analyzer. These features make it simple to handle code and prove helpful for refactoring quickly.This book introduces you to improving a software system's design through refactoring. It begins with simple refactoring and works its way through complex refactoring. You will learn how to change the design of your software system and how to prioritize refactorings—including how to use various Visual Studio features to focus and prioritize design changes. The book also covers how to ensure quality in the light of seemingly drastic changes to a software system. You will also be able to apply standard established principles and patterns as part of the refactoring effort with the help of this book. You will be able to support your evolving code base by refactoring architectural behavior. As an end result, you will have an adaptable system with improved code readability, maintainability, and navigability.
Table of Contents (17 chapters)
Refactoring with Microsoft Visual Studio 2010
Credits
About the Author
Acknowledgement
About the Reviewers
Preface
6
Improving Class Quality
9
Improving Architectural Behavior

Simple refactoring


Simple refactorings are often supported by tools IDEs, IDE add-ons, or stand-alone tools. Many simple refactorings have been done by programmers since they started programming.

A simple refactoring is generally a refactoring that can occur conceptually in one step usually a change to a single artefact and doesn’t involve a change in program flow. The following are examples of simple refactorings that we'll look at in more detail:

  • Renaming a variable

  • Extracting a method

  • Renaming a method

  • Encapsulating a field

  • Extracting a interface

  • Reordering parameters

Renaming a variable, is a simple refactoring that has a very narrow scope generally limited to a very small piece of code. Renaming a variable is often done manually because of its simplicity. Prior to having automated refactorings, the rename variable refactoring could often be done reliably with search and replace.

The Extract method refactoring is a type of composing method refactoring. Performing an extract method refactoring involves creating a new method, copying code from an existing method and replacing it with a call to the new method. Performing this refactoring can involve use of local variables outside the scope of the original code that would then become new parameters added to the new method. This refactoring is useful for abstracting blocks of code to reduce repetition or to make the code more explicit.

Another simple refactoring is Rename method. Renaming method is a simplification refactoring. It has a scope whose change can impact much of a code base. A public method on a class, when renamed, could impact code throughout much of the system if the method is highly coupled. Performing the refactoring rename method involves renaming the method, then renaming all the references to that method through all the code.

Encapsulating a field is an abstraction refactoring. Encapsulating a field involves removing a field from the public interface of a class and replacing it with accessors. Performing an encapsulate field refactoring may involve simply making the field private and adding a getter and a setter. All references to the original field need to be replaced with calls to the getter or the setter. Once a field is encapsulated, its implementation is then abstracted from the public interface of the class and can no longer be coupled to external code freeing it to evolve and change independently of the interface. This abstracting decreases coupling to implementation and increases the maintainability of code.

Another simple abstraction refactoring is Extract interface. Performing an extract interface refactoring involves creating a new interface; copying one or more method signatures from an existing class to the new interfaces, then having that class implement the interface. This is usually done to decouple use of this class and is usually followed up by replacing references to the class with references to the new interface. This refactoring is often used in more complex refactorings, as we'll see in later chapters.

Reording parameters is a simple refactoring whose process is well described by the name. Performing reorder parameters, as its name describes, involves reordering the parameters to a method. This refactoring is useful if you find that the order of the parameters of a method make it more prone to error (two adjacent parameters of the same type) or that you need to make the method signature match another (maybe newly inherited) method. If the method is referenced, the order in which the arguments are passed to the method would need to be reordered. Although a simple refactoring, conceptually this refactoring could lead to logic errors in code if not fully completed. If parameters that were reordered in the method signature had the same type, all references to the method would be syntactically correct and the code would recompile without error. This could lead to arguments being passed as parameters to a method that were not passed to the method before "refactoring". If this refactoring is not done properly it is no longer a refactoring because the external behavior of the code has changed! Reording parameters is different from the previously mentioned simple refactorings, because if not completed properly they would all result in a compiler error.

Removing parameters is another simplification refactoring. It involves removing one or more parameters from a method signature. If the method is referenced, these references would need to be modified to remove the argument that is no longer used. This refactoring is often in response to code modifications where method parameters are no longer used. This could be the result of a refactoring or an external behavior change. With object-oriented languages, removing a parameter could cause a compiler error as removing the parameter could cause the method signature to be identical to an existing method overload. If there were an existing overload, it would be hard to tell which method references actually referenced the overload or the method with the newly removed parameter. In cases such as these, it's usually best to revert the change and reevaluate the two methods.

These simple refactorings are conceptually easy and aren't difficult to perform manually. Performed manually, these refactorings could easily involve many lines of code with a lot of repetitive code changes. With many repetitive actions and the possibility of introducing human error, many developers may tend to avoid performing these manual refactorings despite being simple. These refactorings have the potential to evolve the code in ways that make it easier to maintain it and add features to it. This makes for more robust code and enables you to more quickl respond to new requirements.

These simple refactorings are actually supported by Visual Studio® 2010. Visual Studio® 2010 automates these refactorings. If you rename a method with the rename method refactoring in Visual Studio® 2010 and there are hundreds of references to the method, Visual Studio® 2010 will find all references to them in the current solution and rename them all automatically. This drastically reduces the friction of performing many of the refactoring building blocks.

In Chapter 2, we began performing these simple refactorings with the built-in refactoring tools in Visual Studio® 2010.

Simple refactorings are refactorings that are easy to understand, easy to describe, and easy to implement. Simple refactorings apply to software projects in just about every language they transcend languages. Refactorings are like recipes or patterns; they describe (sometimes merely by their name) how to improve or change code. This simplicity with which they can describe change and the simplicity by which they are known has led to several taxonomies of refactorings. Most taxonomies catalogue simple refactorings; but some taxonomies can be found that include complex or specialized refactorings. Some examples of online taxonomies offer centralized databases of refactorings:

http://www.refactoring.com/catalog/

http://industriallogic.com/xp/refactoring/catalog.html