| T O P I C R E V I E W |
| Curtis |
Posted - Feb 15 2007 : 12:56:17 PM
Visual Studio 2005 has a refactoring feature that will implement an interface on a class. It is a useful feature. What would make it more useful is the option of creating default variables automatically such as:
class Phone : IPhoneInterface
{
bool _intercom; // "Implement Interface" doesn't create this variable
public bool Intercom
{
get { return _intercom; }
set { _intercom = value; }
}
}
So, in the same way the "Encapsulate Field" feature works in VA X, the Implement Interface would also work by creating the variables and public fields of the implemented interface.
Hope this makes sense.
Curtis |
| 7 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Feb 16 2007 : 1:22:24 PM
For now you can try assigning a keyboard shortcut to "VAssistX.EncapsulateField"
Combine this with editing the autotext entry to suit your needs and you may find this is a very quick and easy way of generating this code. |
| Curtis |
Posted - Feb 16 2007 : 11:25:27 AM
quote:
Originally posted by feline
For this situation, where you simply want default get / set functions for each member variable I can see the appeal of default function's that "just work". There is already a feature request in to allow Encapsulate Field to work on several member variables at once, but this would not remove the existing exception throwing functions the IDE has inserted. I don't want to go down the road of searching for and automatically removing existing functions, that just sounds to dangerous.
Thanks feline. You and sl@sh make a valid point about mass code generation. I'd still like to have the option of generating variables for all properties on an interface, but doing it without asking first could cause problems.
Also, I had not thought of the autotext feature in VA. There may be something there that I can use.
I'm looking forward to seeing the feature request you mentioned above. With that alone, depending on how it's done, my request could be satisfied.
Again, thanks for looking into this.
Curtis |
| feline |
Posted - Feb 16 2007 : 07:35:38 AM
sl@sh you are quite right about Intercom, thank you  , re-reading the code more carefully I can see what is happening now. I am so used to code that is indented and syntax highlighted that "plain text" code just gets hard to understand Plus I do very little work in C#
Arguably VA's default autotext for Encapsulate Field fall into this same trap, but since they are simply autotext rules you are free to change them to throw exceptions instead. Of course this assumes the C++ code is actually catching exceptions, but that is a different problem entirely
For this situation, where you simply want default get / set functions for each member variable I can see the appeal of default function's that "just work". There is already a feature request in to allow Encapsulate Field to work on several member variables at once, but this would not remove the existing exception throwing functions the IDE has inserted. I don't want to go down the road of searching for and automatically removing existing functions, that just sounds to dangerous. |
| sl@sh |
Posted - Feb 16 2007 : 03:49:53 AM
I haven't seen a thing about C#, but Curtis did point out that Intercom is not an attribute but a property - apparently there is a difference. The interface declaration just names this property, whereas the class implementation has to define it. (Looks a lot like Delphi object properties to me)
This is not why I answered to this thread however  . I just wanted to point out that for large projects I consider the 'throw exception' approach much safer and more sensible than the 'wild guess' approach: people using code generation a lot tend to not take another look at what they actually generated. So if there is any problem with the default-generated code it usually takes a considerable amount of time just to find out there is a problem, and where it comes from. Anyone testing the VS-generated implementation though will immediately be pointed to the right spot.
Hence, I wouldn't recommended a one-step conversion from Interface to class implementation. Maybe something on the level of 'property implementation' would be safer? Or at least that is my PoV from the angle of a C++ programmer.
|
| feline |
Posted - Feb 15 2007 : 3:30:33 PM
That makes sense, thank you. In the final code sample you have two member variables, one that has the same name as the variable in the Interface, and one with a slightly different name.
Generalising from C++ (where I am more familiar) I would have expected Phone to inherit the variable IPhone::Intercom, so there would be no need to add it to the class Phone.
The other thing I am wondering about, is why does your final version return "_intercom" rather than "Intercom"?
I am currently trying to think of a sensible way to "extend" the existing IDE refactoring, rather than re-writing it in VA, but I am developing the horrible feeling this is not going to work *doh* |
| Curtis |
Posted - Feb 15 2007 : 2:05:07 PM
quote:
Originally posted by feline
I assume this is C#?
I am confused by the statement "implement an interface on a class"
I have some idea of what a C# interface is, but this statement does not make much sense to me. Can you explain in basic terms what this refactoring is supposed to do?
No problem... and thanks for asking for clarification.
Yes, this example is in C#.
Basically, when you create a class in C# (or VB.NET) you can specify an interface that you want the class to implement. So, let's say there is a interface called IPhone that is defined like this:
interface IPhone
{
bool Intercom { get; }
}
The IPhone interface has a single property member called Intercom.
Now, if I want to implement that interface in/on a class i would write some code like this:
class Phone : IPhone // a Phone class that implements the IPhone interface
{
}
Now, at this point, in VS2005, if you right-click on the word "IPhone", a popup menu will allow you to "Implement the Interface" that you've right-clicked on. If you select that menu item the code will change to:
class Phone : IPhone // a Phone class that implements the IPhone interface
{
bool Intercom
{
get { throw new Exception("The method or operation is not implemented."); }
}
}
Note that the stub created by VS2005 simply throws an exception rather than defining a variable and returning that variable.
So, to finish the code you would define a variable for Intercom and have it returned from the Intercom property like, for instance:
class Phone : IPhone // a Phone class that implements the IPhone interface
{
bool _intercom;
bool Intercom
{
get { return _intercom; }
}
}
The feature I'm requesting would create the code above for you rather than a stub that throws an exception like VS2005 does.
Make sense?
Curtis |
| feline |
Posted - Feb 15 2007 : 1:07:39 PM
I assume this is C#?
I am confused by the statement "implement an interface on a class"
I have some idea of what a C# interface is, but this statement does not make much sense to me. Can you explain in basic terms what this refactoring is supposed to do? |
|
|
