Understanding Interface-Based Programming - Interface Refactoring
(Page 5 of 5 )
Code refactoring allows you to change the code structure without changing or affecting what the code itself actually does. Changing a variable name or packaging a few lines of code into a method are examples of code refactoring. Visual Studio 2005 contains a simple refactoring engine that enables several actions, including renaming types, variables, methods, or parameters; extracting a method out of a code section (and inserting a method call instead); encapsulating type members as properties; automating many formatting tasks; and auto-expanding common statements. The main difference between C# refactoring and doing a mere edit or find-and-replace is that you can harness the intelligence of the compiler to distinguish between code and comments, and so on.
In Visual Studio 2005, refactoring changes are limited to a single solution and do not propagate to client assemblies in different solutions.
You can invoke refactoring in two ways: you can select Refactor from the top-level Visual Studio 2005 menu, or you can select it from the pop-up context menu.
Of particular interest in the context of this chapter is the refactoring ability to extract an interface definition out of a set of public methods the type implements. For example, consider the followingCalculatorclass:
public abstract class Calculator
{
public int Add(int argument1,int argument2)
{
return argument1 + argument2;
}
public int Subtract(int argument1,int argument2)
{
return argument1 - argument2;
}
public virtual int Divide(int argument1,int argument2)
{
return argument1 + argument2;
}
public abstract int Multiply(int argument1,int argument2);
}
To extract an interface out of theCalculatorclass, right-click anywhere inside the class definition and select Extract Interface… from the Refactor menu. This will bring up the Extract Interface dialog box, shown in Figure 3-3.
The dialog box will propose a name for the interface: the type’s name, prefixed with anI. The refactoring will use the default (also called root) namespace of the project, as configured in the project settings.

Figure 3-3. The Extract Interface dialog box
The interface will be extracted to a separate file, which will automatically be added to the project. You can provide a filename in the dialog. Finally, all the public methods (or properties) of the type will be listed in the dialog, regardless of whether they are public, virtual, or abstract. Note that when a class hierarchy is involved, the refactoring engine will only include public methods explicitly declared by the class or overridden by it. To include the suggested methods in the new interface definition, you must explicitly check the checkboxes to the left of each method. After you click the OK button, the new interface will be placed in the specified new file, and Visual Studio 2005 will add the interface derivation to theCalculator class, as shown here:
//In the file ICalculator.cs
interface ICalculator
{
int Add(int argument1,int argument2);
int Divide(int argument1,int argument2);
int Multiply(int argument1,int argument2);
int Subtruct(int argument1,int argument2);
}
//In the file Calculator.cs
public abstract class Calculator : ICalculator
{...}
Note that the extracted interface is internal, and that you have to explicitly make it public.
You can also extract one interface from the definition of another, in which case the new interface will be placed in a new file, but the original interface definition will not change (i.e., it will not inherit from the new interface). Visual Studio 2005 will not prefix the new interface name with anI, because that would result in a doubleII. Instead, it will append an ordinal number to the interface name.
Note that if the type already implements an interface implicitly, that interface’s members will be included in the list in the Extract Interface dialog. Use explicit interface implementation on existing interfaces to avoid including them in the refactoring.
* See the Abstract Factory design pattern in Design Patterns, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley).
* If you are not familiar with generics, Appendix D provides a concise overview.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
This article is excerpted from chapter three of Programming .NET Components, Second Edition, written by Juval Lowy (O'Reilly, 2006; ISBN: 0596007620). Check it out today at your favorite bookstore. Buy this book now.
|
|