How to implement an interface in VB.Net when two methods have the same name but different parameters - vb.net

I am a C# programmer but I have to work with some VB.Net code and I came across a situation where I have two methods on an interface with the same name but different method parameters. When I attempt to implement this interface in a class, VB.Net requires explicitly declaring "Implements MethodName" after the method signature. Since both method names are identical, this is confusing the compiler. Is there a way to get around this sort of problem? I suspect this must be a common occurrence. Any thoughts?
N.B. This was more a case of the programmer not verifying that the interface in question had not changed from underneath him.

How is this confusing the compiler?
The compiler expects to find an implementation for every method signature, and distinguishes the implementations by their signatures.
If the signatures are identical/undistinguishable (in most cases it means that the arguments are of the same types in the same order) you'll get a design-time error related to the interface, saying that the two methods cannot overload eachother as they have the same signature.
So, in any case, the compiler should not be confused.
Should you need further assistance, please attach a code sample - these things are relatively easy to resolve.
Tip: When writing the implementation, as soon as you write down "implements MyInterface" and hit Enter - Visual Studio will create a "skeleton" code of the implementation, which saves you writing the method signatures and correlating them to the interface.
Example code of having two methods with the same name and everythign working well:
Interface MyInterface
Sub MySub(ByVal arg0 As DateTime)
Sub MySub(ByVal arg0 As ULong)
End Interface
Class MyImplementation
Implements MyInterface
Public Sub MySub(ByVal arg0 As Date) Implements MyInterface.MySub
...
End Sub
Public Sub MySub(ByVal arg0 As ULong) Implements MyInterface.MySub
...
End Sub
End Class

You can make the method private and give it another name.
Like:
Private Sub SaveImpl(ByVal someEntity As IEntity) Implements IRepository.Save
this will look to the outside like: someRepository.Save

Related

How to extend derived classes by defining class(es) that exposes the instance as a property

I have a class that I would like to extend by defining a new class that contains the first class as a public property, as well as additional added properties. However, the class that I'm extending has multiple derived types, which should be treated the same in the extension class.
Below is an example of what I am trying to do:
Public Class ClassA
End Class
Public Class ClassB
Inherits ClassA
End Class
Public Class ClassC
Inherits ClassA
End Class
Public Class BaseExtended
Public Property Foo As ClassA
Public Property ExtendedMetaData1 As Double
Public Property ExtendedMetaData12 As Integer
End Class
Public Class DerivedExtendedB
Inherits BaseExtended
Public Property Foo As ClassB
End Class
Public Class DerivedExtendedC
Inherits BaseExtended
Public Property Foo As ClassC
End Class
The code that uses an instance of any of the 'extended' classes would then need use that instance appropriately depending on it's type. There would be many cases where the property 'Foo' needs to be accessed and modified outside of the class that it belongs to.
If I were to implement something like what I have shown above, that would require that I first cast it to the required type before accessing or modifying it. Ideally I would like to do that inside the 'DerivedExtended' class; The alternative, I think, would be to duplicate code to cast that property would [hundreds of times] in the client code.
Private Sub ClientUsesObject(bar As BaseExtended)
' Perform a task that is agnostic Foo type
' Would not require that Foo be cast to any specific type
If bar.GetType() Is GetType(DerivedExtendedB) Then
Dim barCast As DerivedExtendedB = DirectCast(bar, DerivedExtendedB)
' Perform task that requires Foo to be of type ClassB
ElseIf bar.GetType() Is GetType(DerivedExtendedC) Then
Dim barCast As DerivedExtendedC = DirectCast(bar, DerivedExtendedC)
' Perform task that requires Foo to be of type ClassC
End If
End Sub
What I'm looking for is advice outlining or describing a design pattern that can handle this situation. I've searched for quite a while, and have not been able to find any examples that solve this problem.
I realize that this may be somewhat of an "XY" problem. I'm working with existing code that simply assumes all instances are of the same derived type (when in fact some instances are of the other derived type). As such, the existing code does not work. To me what I've tried to outline above seems like the most straightforward path, but I'm open to alternative if this is just the wrong approach.
This pattern of type covariance in derived classes is the canonical reason for what is called in C++ the "Curiously Recurring Template Pattern" and has been called in .NET the "Curiously Recurring Generic Pattern." I believe it's also sometimes referred to as "F-Bounded Polymorphism" (not a computer scientist, so I might have the reference wrong).
You can write a base class like this:
Public Class Base(Of TDerived As Base)
Public Overridable Property foo As TDerived
End Class
And then use it like this:
Public Class MyDerived
Inherits Base(Of MyDerived)
End Class
Then, the derived class has a property foo whose type is MyDerived. No casting required by clients.
However, this has some limitations. It works best when you don't need to switch back and forth between derived and base. There is no one Base, so you can't declare instances of it. If you want to be able to declare something as Base, then you end up needing to fall back on a non-generic base class. This will still work well for certain usage patterns where you don't need to convert from base to derived, but otherwise you run right back into the casting problems you are trying to avoid.
Eric Lippert has written a bit about this pattern. He's always interesting to read, so I'd recommend looking up his commentary.
Another alternative to consider, if the generic approach doesn't work for you, is code generation. You can use T4 templates to process a compact description of what your code should be, and generate the code files from them. A long list of casts is less tedious if you only write the machinery to generate it, you don't write them all out explicitly.

Using interface function defined in DLL

I'm using an interface defined in a DLL.
When I call...
m.GetMasterVolumeLevelScalar(btVol)
... I get a Null Reference Exception because "m" is nothing.
However, I can't use "new" on this interface.
How would I use this interface correctly?
I did read on implements, but I didn't find an example similar to this interface.
Thank you.
Edit: I know now that I need to type
Implements Vannatech.CoreAudio.Interfaces.IAudioEndpointVolume
and the functions will automatically be added to my class.
However, I'm not sure what to do with the NonImplementedException for example here:
Public Function GetMasterVolumeLevelScalar(ByRef level As Single) As Integer Implements IAudioEndpointVolume.GetMasterVolumeLevelScalar
Throw New NotImplementedException()
End Function
I got it:
I simply need to type
Implements Vannatech.CoreAudio.Interfaces.IAudioEndpointVolume
By doing that, all functions will automatically be added to the class in which I typed this.
I just didn't scroll down enough to see that.

Compiler doesn't see CompareTo method in IComparable(Of T) object

I'm trying to apply the answer to Implementing generic IComparer in VB to my project by implementing an IComparable interface for a class in VB.NET. The section for the GenericComparer in that answer compiles fine, but the IComparable interface on my specific object won't get past the compiler.
Public Class RowAndRanking
Implements IComparable(Of RowAndRanking)
Public html As String
Public rank As Double
Public Function CompareTo(other As RowAndRanking) As Integer
Return Math.Round(Me.rank - other.rank)
End Function
End Class
The compiler keeps insisting that "Class 'RowAndRanking' must implement 'Function CompareTo(other As RowAndRanking) As Integer' for interface 'System.IComparable(Of RowAndRanking)'.", but looking at my code, I can see that method signature. Furthermore, if I go to where I'm trying to run a Sort on a List of these objects, I can type:
Dim row as RowAndRanking = new RowAndRanking
row.CompareTo(...
And Visual Studio's code complete picks up the method signature.
I've tried cleaning and rebuilding the project, but the issue remains. I've tried changing it to use a non-generic comparer solution, but the compiler still doesn't see the CompareTo method. This should be simple, but the compiler just doesn't see the function. Has this happened to anyone else? Is there something else that I can try?
Unlike C#, VB requires that you explicitly mark implementing methods.
Add
Implements IComparable(Of RowAndRanking).CompareTo

Can I qualify the type of a parameter in VB.NET?

This is kind of two questions (one more specific than the other).
If I have a method like this:
Public Function Blah(String Foo)
End Function
Can I qualify Foo against another type (for instance can I require that Foo be a String that also implements IInterface?).
I'm imagining something vaguely similar to this:
Public Function Blah(RandomObject Foo Where RandomObject Is IInterface)
End Function
Additionally, is there any way to qualify the Type parameter?
For instance, can I require that the Type I take as a parameter is of a particular class tree?
Public Function Blah(Type t Where Type Of String)
End Function
I should mention that I am using this in the context of a property of an attribute so the class declaration itself cannot be generic (this is purely focused on qualifying a method parameter rather than typing a class and its methods).
This looks like a case for generics to me. Your method signature would be something like this in VB.NET:
Public Function Blah(Of T As {IImplementedByT})(Foo As T)
This specifies that Foo can be of any type T as long as T implements IImplementedByT. Note that this method can be generic without the containing class needing to be generic. If you want T to be a class derived from RandomClass that also implements this interface, you can specify both constraints:
Public Function Blah(Of T As {RandomClass, IImplementedByT})(Foo As T)
You can do the first for a generic type, but not for a nongeneric type. Basically a variable (including a parameter) can only have one compile-time type, so you can't say "it has to be a Foo and an IBar - you have to pick one or the other. Generics let you say "it has to be some type T where T derives from Foo and implements IBar" though.
Generics is a huge topic - too big to cover in a Stack Overflow answer - but Microsoft has a good introductory article.
As for your second question - no, you can't do that. The Type value will only be known at execution time, so it has to be an execution time check. You can write that check fairly easily though, with Type.IsAssignableFrom.
Not sure what you mean by "Foo be a String that also implements IInterface".
string class is sealed, so you can't inherit from it & hence you cant implement an interface on top of it.
I hope I am on the right page.

MyClass in VB.Net

What is a realistic use for VB.Net's MyClass keyword?
I understand the technical usage of MyClass; I don't understand the practical usage of it in the real world.
Using MyClass only makes sense if you have any virtual (overridable) members. But it also means that you want to ignore the overridden implementations in sub classes. It appears to be self-contradicting.
I can think of some contrived examples, but they are simply bad design rather than practical usage.
MyClass, from a compiler's perspective, is a way to omit a callvirt instruction in favor of a call instruction. Essentially when you call a method with the virtual semantics (callvirt), you're indicating that you want to use the most derived variation. In cases where you wish to omit the derived variations you utilize MyClass (call). While you've stated you understand the basic concept, I figured it might help to describe it from a functional viewpoint, rather than an implicit understanding. It's functionally identical to MyBase with the caveat of scope being base type with MyBase, instead of the active type with MyClass.
Overriding virtual call semantics, at the current point in the hierarchy, is typically a bad design choice, the only times it is valid is when you must rely on a specific piece of functionality within your object's hierarchy, and can't rely on the inheritor to call your variation through a base invocation in their implementation. It could also rely on you as a designer deciding that it's the only alternative since you overrode the functionality further in the object hierarchy and you must ensure that in this corner case that this specific method, at the current level of the inheritance tree, must be called.
It's all about design, understanding the overall design and corner cases. There's likely a reason C♯ doesn't include such functionality since on those corner cases you could separate the method into a private variation the current level in the hierarchy invokes, and just refer to that private implementation when necessary. It's my personal view that utilizing the segmentation approach is the ideal means to an end since it's explicit about your design choice, and is easier to follow (and it's also the only valid means in languages without a functional equivalent to MyClass.)
Polymorphism
I'm sorry I don't have a clear code example here but you can follow the link below for that and I hate to copy the MSDN Library description but it's so good that it's really hard to rewrite it any clearer.
"MyClass provides a way to refer to the current class instance members without them being replaced by any derived class overrides. The MyClass keyword behaves like an object variable referring to the current instance of a class as originally implemented."
Also note that you can't use MyClass in a shared method.
A good example of implementing Polymorphism via MyClass is at http://www.devarticles.com/c/a/VB.Net/Implementing-Polymorphism-in-VB.Net/
I guess the only case I could see a use for it, would be if you want the base condition, and an inherited condition at the same time? I.E. where you want to be able to inherit a member, but you want the ability to access a value for that member that hasn't been changed by inheritance?
You need it if you want to call a chained constructor.
Public Sub New(ByVal accountKey As Integer)
MyClass.New(accountKey, Nothing)
End Sub
Public Sub New(ByVal accountKey As Integer, ByVal accountName As String)
MyClass.New(accountKey, accountName, Nothing)
End Sub
Public Sub New(ByVal accountKey As Integer, ByVal accountName As String, ByVal accountNumber As String)
m_AccountKey = accountKey
m_AccountName = accountName
m_AccountNumber = accountNumber
End Sub