Implementing Inherited Interface with Overloaded Member vb.net - vb.net

I am trying to implement a derived interface in a class. My interfaces and class are similar to the following. The Namespaces relate to different projects that hold these interfaces and the class:
Namespace ns1
Public Interface IParent
Function myFunction() As Double
End Interface
End ns1
Namespace ns2
Public Interface IDerived
Inherits ns1.IParent
Overloads / Shadows Function myFunction(ByRef myObject as Object) As Double
End Interface
End ns2
Namespace ns3
Public Class myClass
Implements ns2.IDerived
Public Function myFunction(ByRef obj as Object) As Double Implements ns2.IDerived.myFunction
End Function
End ns3
In the derived interface, I am trying to overload the function in a way that when I implement the derived interface, I only have to implement the function as defined therein - as is done with the code above on "myClass". However, I am getting an error saying I have to also implement the function from the parent interface (with the empty argument list). The error exists regardless of my using Overloads or Shadows on the function in the derived interface - both cause the error.
Is there anyway to accomplish what I am trying to do - implement only the derived interface's function in my class - using interfaces? If there is not a way using interfaces, can anyone suggest an alternate way? We really need to use interfaces and are trying to avoid using classes. That said, abstract classes my allow us to do all we need to do with these.
I have read a lot of info on all the topics covered by this question as every concept is pretty basic and well covered in online help. But, I have not found anything that I recognize as a direct solution to my specific issue.
Thanks in advance for any help.

I don't know if this is a typo but you have two distinct methods: one that takes no parameter, and another that takes an object, so the compiler requirement is legitimate.
If this is a typo and that you have only one method, say "myFunction()", then I fear VB.Net does not act like C# by simply hiding the base interface and allowing to only implement the derived one.
But you could easily fix this by forwarding:
Namespace ns1
Public Interface IParent
Function myFunction() As Double
End Interface
End Namespace
Namespace ns2
Public Interface IDerived
Inherits ns1.IParent
Function myFunction() As Double
End Interface
End Namespace
Namespace ns3
Public Class Class1
Implements ns2.IDerived
Public Function myFunction() As Double Implements ns2.IDerived.myFunction
Return 42
End Function
Private Function myFunction1() As Double Implements ns1.IParent.myFunction
Return myFunction()
End Function
End Class
End Namespace
Module Module1
Sub Main()
Dim cp As ns1.IParent = New ns3.Class1
cp.myFunction()
Dim cd As ns2.IDerived = New ns3.Class1
cd.myFunction()
End Sub
End Module
EDIT:
So was not a typo, here is the standard (good/best practice?) fix:
Public Class Class1
Implements ns2.IDerived
Public Function myFunction(ByRef obj As Object) As Double Implements ns2.IDerived.myFunction
End Function
Public Function myFunction() As Double Implements ns1.IParent.myFunction
Throw New NotImplementedException("'ns1.IParent.myFunction' has not been implemented because unicorns can't fly!")
End Function
End Class

I don't believe that what you want to accomplish is possible the way you are trying... As I recall when you inherit an Interface any class that implements your derived Interface is actually being told that it must implement both Interfaces rather allowing the options you have in a full class.
So effectively what you have in myClass is:
Namespace ns3
Public Class myClass
Implements ns2.IDerived
Implements ns1.IParent
Public Function myFunction(ByRef obj as Object) As Double Implements ns2.IDerived.myFunction
End Function
End ns3
So inheriting an interface is really just a way to enforce that a class implementing the derived interface must also implement the base interface.

Related

How do I refer to two different classes by one name in vb.net

I have two classes to handle database operations, one for MySQL (DBMySQL), and another for SQLite (DBSQLite). The user chooses which database system to use.
The functions within the classes have the same names, but are obviously slightly different to handle the variations in databases.
I would like to refer to the chosen class by one name throughout the application. I have set a global variable DB.
In a procedure I can: Dim DB as New DBMySQL (or DBSQLite). This works within the procedure, but not globally, but I can see all the functions when coding.
If I instead use: DB = New DBMySQL, this works globally, but no class functions are displayed when coding.
Any alternatives?
Use the concept of inheritance, and create a MustInherit class with MustOverride methods and/or properties.
Public MustInherit Class AbstractDB
Public MustOverride Function MyQuery(input As Object) As Object
Public MustOverride Sub MyUpdateMethod(input As Object)
End Class
Public Class DBMySQL
Inherits AbstractDB
Public Overrides Function MyQuery(input As Object) As Object
End Function
Public Overrides Sub MyUpdateMethod(input As Object)
End Sub
End Class
Public Class DBSQLite
Inherits AbstractDB
Public Overrides Function MyQuery(input As Object) As Object
End Function
Public Overrides Sub MyUpdateMethod(input As Object)
End Sub
End Class
Then, when you want to use your classes, make your DB global variable of type AbstractDB. You could then create either DBMySql or DBSQLite and assign it to your DB variable. The method names will all be the same, because they all inherit the same base class. But each derived class must fill out the content of those methods on its own.
Dim DB as AbstractDB = New DBMySQL
You could also use an interface.
Public Interface IRepository
' common functions of MySQL and SQLLiteclasses
End Interface
Public Class MySQLRepository
Implements IRepository
End Class
Public Class SQLLiteRepository
Implements IRepository
End Class
Public Function GetDB(userChoice As String) As IRepository
If userChoice = "MySQL" Then
Return New MySQLRepository()
Else
Return New SQLLiteRepository
End if
End Function
Dim DB As IRepository = GetDB(userChoice)
This is a basic implementation of the Repository pattern. The example in the link is in C#, but, as you're probably aware, it's not easy finding examples in VB. Fortunately, there are lots of C# to VB converters.
The abstract example Sean Skelly gave should also work. You may want to research the difference between abstract classes and interfaces.

Issue with generics, interfaces, and casting

I recently added an interface to some custom user controls I have implemented. The interface is pretty basic. It has one method that supports chaining:
Public Interface IMyInterface(Of T As WebControl)
Function DoSomething() As T
End Interface
The implementations are also pretty basic:
Public Class MyCustomControl
Inherits CompositeControl
Implements IMyInterface(Of MyCustomControl)
Public Function DoSomething() As MyCustomControl _
Implements IMyInterface(Of MyCustomControl).DoSomething
' do stuff
Return Me
End Class
Everything works fine up to this point. The issues arise when I attempt to loop over a collection of controls that all implement the IMyInterface interface, like so:
Dim myList = New List(Of IMyInterface(Of WebControl))
myList.Add(someCustomControl)
myList.ForEach(Sub(i) i.DoSomething())
someCustomControl is a MyCustomControl which implements IMyInterface(Of MyCustomControl) instead of IMyInterface(Of WebControl).
I am getting this error on the second line (where I try to add someCustomControl):
Option Strict On disallows implicit conversions from 'MyCustomControl' to 'IMyInterface(Of WebControl)'.
Is there any way to get around this error? I am close to having it working but I do not know enough about generics to get beyond this point.
Covariance is a language feature that was introduced in VS 2010, and solves your problem. You need to define your generic such that the type T has the Out keyword in front of it:
Public Interface IMyInterface(Of Out T As WebControl)
Function DoSomething() As T
End Interface
When you use the Out keyword, you are using covariance. It allows generics of a more derived type to be used in place of a generic with the base type. So in your case it will allow a IMyInterface(Of MyCustomControl)) object in places where the code would normally expect IMyInterface(Of WebControl)), such as your for loop.
Note that covariance has a restriction. The covariant type T can only be used as a function return value, and not as a parameter into a function (or sub). For example, if the DoSomething signature in IMyInterface looked like this the compiler would complain:
' Here the type T is used as an input param - compiler error
Sub DoSomething(ByVal sampleArg As T)
Given your chaining scenario, I don't think the above restriction is a problem.
More Info at MSDN:
Covariance and Contravariance
Creating Variant Generic Interfaces
I don't know what your function DoSomething does, but I try assigning the instance's CssClass in there for testing purpose.
Declare the interface as follows:
Public Interface IMyInterface(Of Out T As WebControl)
Function DoSomething() As T
End Interface
Notice the Out T parameter.
Create 2 controls that implement the interface:
Public Class MyCustomControl1
Inherits CompositeControl
Implements IMyInterface(Of MyCustomControl1)
Public Function DoSomething() As MyCustomControl1 Implements IMyInterface(Of MyCustomControl1).DoSomething
' do stuff
Me.CssClass = "XXX"
Return Me
End Function
End Class
Public Class MyCustomControl2
Inherits CompositeControl
Implements IMyInterface(Of MyCustomControl2)
Public Function DoSomething() As MyCustomControl2 Implements IMyInterface(Of MyCustomControl2).DoSomething
' do stuff
Me.CssClass = "YYY"
Return Me
End Function
End Class
On a test page's PageLoad event:
Dim someCustomControl As New MyCustomControl1
Dim someCustomControl2 As New MyCustomControl2
Dim myList = New List(Of IMyInterface(Of WebControl))
myList.Add(someCustomControl)
myList.Add(someCustomControl2)
myList.ForEach(Sub(i) Literal1.Text &= i.DoSomething.CssClass & "<br />")
The result is, the CssClass property of both someCustomControl & someCustomControl2 are set to the respective values.
This shows that the interface function DoSomething was successfully called and the instance changed.
You will need to cast the object before adding it:
myList.Add(CType(someCustomControl, IMyInterface(Of WebControl)))
You may also want to concider making the interface not generic and your "DoWork" method return type as the interface itself.
Public Interface IMyInterface
Function DoSomething() As IMyInterface
End Interface
When you have to specify the type in the interface definition it kind of takes away from the power of interfaces (not having to know about the implementation).

How to get the class type in a inherited shared method

Folks;
Code looks like:
Public Class MasterA
Inherits Underling
End Class
Public Class MasterB
Inherits Underling
End Class
Public Mustinherit Class Underling
Sub DoSomething()
Me.GetType 'Using the instance, I can get the class.
end sub
Shared function() as ???? 'How can I define the return type based on the class that inherited me?
'Me.GetType 'Won't work as this is a shared function with no instance 'Me'
End Function
End class
OK. The question is: is there a way to get at the class type from within a shared function that was inherited by another class?
What I'm building is an XML serializer/desrializer as an inheritable class so that classes that inherit it can be serilized to an XML file, and back again. Rather than writing a serializer/deserializer for each type of class I want to do this with, I'd like to just inherit the functionality.
To do that, though, requires that I be able to ascertain the clas that inherited me in the shared function.
You could get the desired behavior with a generic base class, my VB is a little rusty so you might find stray parens or brackets. This would really be the only way to get a type reference to an inheriting class in a shared base class function.
Public Mustinherit Class Underling(Of T)
Sub DoSomething()
Me.GetType 'Using the instance, I can get the class.
end sub
Shared function() As T
' GetType(T) should get the type at this point
End Function
End class
Public Class MasterA
Inherits Underling(Of MasterA)
End Class
Public Class MasterB
Inherits Underling(Of MasterB)
End Class
As a side note it does seem like a rather weird solution to handle XmlSerialization rather than through your own serializer implementation or XmlSerializer

Using abstract generic classes in software design factory pattern

I have a bit of a design issue. I created a rate calculator as follows :
Public Interface ICalculator
Property PaymentTerm As Double
Function Calculate() As CommissionValues
ReadOnly Property CalculationRule As CalculationRuleEnum
End Interface
Public Interface IFlexibleRateCalculator
Inherits ICalculator
Property TransferRate As Decimal
End Interface
Public Interface IFixedRateCalculator
Inherits ICalculator
Property ContractRate As Decimal
End Interface
Public Interface IRateSettingBase
Property RateType As RateTypeEnum
ReadOnly Property Calculator As ICalculator
End Interface
Public MustInherit Class RateSetting
Implements IRateSettingBase
Public MustOverride ReadOnly Property Calculator() As ICalculator Implements IRateSettingBase.Calculator
I can do something like this:
dim ratevalues as RateValues = RateSetting().Calculator.Calculate()
Pretty simple. The problem is that each type of calculator has their own set of properties that need to be set in order for their Calculate() methods to work properly.
So I end up having to implement as follows
FlexibleRateCalculator
Implements IFlexibleRateCalculator
Private mRequestedRate As Decimal
Public Function Calculate() As RateValues Implements ICalculator.Calculate
FixedRateCalculator
Implements IFixedRateCalculator
Private mTransferRate As Decimal
Public Function Calculate() As RateValues Implements ICalculator.Calculate
What is the best way using generics and abstract classes to create a factory pattern that will generate a calculator of a specific type dynamically??
I need a very generic solution as many calculation rates will be added and modified all with their own parameters needed for the calculation logic. I want to be able to do this quickly and possibly control these rate calculation via db. FYI answers in C# or VB.Net are welcome :)
Thanks in advance!
Keep only the ICalculator interface and convert the more specific interfaces to classes. I can't think of a good reason why you would create a class just to store a variable, so I'm going to get rid of the RateSetting entirely.
Public Interface ICalculator
Property Rate As Double
Property PaymentTerm As Double
Function Calculate() As CommissionValues
ReadOnly Property CalculationRule As CalculationRuleEnum
End Interface
Public Class FlexibleRateCalculator : Implements ICalculator
Public Sub New(rate As Double)
Me.Rate = rate
End Sub
'
' ICalculator implementation goes here
'
End Class
Public Class FixedRateCalculator : Implements ICalculator
Public Sub New(rate As Double)
Me.Rate = rate
End Sub
'
' ICalculator implementation goes here
'
End Class
Public Enum RateType
Flexible = 1
Fixed = 2
End Enum
Public Class CalculatorFactory
Public Shared Function GetCalculator(rate As Double, type As RateType) As ICalculator
Select Case type
Case RateType.Flexible
Return New FlexibleRateCalculator(rate)
Case RateType.Fixed
Return New FixedRateCalculator(rate)
Case Else
Throw New ArgumentException
End Select
End Function
End Class
You create object instances by passing a rate and a rate type to the GetCalculator method. I don't know what you mean by CalculationRule, but if it's important to the end user then you should add it as an additional parameter.
You can easily add more calculator types that implement ICalculator, as long as you don't forget to update the select statement in the factory method.
EDIT: of course you can also set additional properties before returning an object instance. The point of this pattern however is to make sure that the end-user does not need to know about how Calculate() is implemented. If you want to make more specific factory methods for every calculator, it kind of defeats the purpose.
Are you familiar with any IoC containers? You should be able use the factory-type services they provide to generate you the appropriate types with appropriate parameters/properties based on a given type (enum, string, etc.)
If not, you could probably create a factory class that has a method that generates the appropriate type based on a parameter. This method could accept a ParamArray or other object that contains the properties needed to correctly set-up the calculator and then return it, via the ICalculator interface.

vb.net implement strategy pattern with different interface

is it possible to implement strategy pattern with different parameters in VB.net?
For example I have the following code:
Public Interface InterfaceDataManipulation
Sub updateMyData()
End Interface
How to implemente updateMyData in the class that implements above interface class with different parameter, for example in class x :
Public Class X
Implements InterfaceDataManipulation
Public Sub updateMyData(ByVal x as String)
Console.Writeline(x)
End Sub
End Class
But the IDE raises an error "class x must implement updateMyData on interface InterfaceDataManipulation"
By adding a parameter you're not implementing the interface - The idea of the interface is that people can use your class by only knowing about the interface -so your sub with parameter wouldn't match their expectations.
There are probably many ways of skinning this cat, but these are a few of the options:
Don't use the interface
Implement your version of updateMyData as an overload, but you should still implement the original without the parameter aswell
Pass in x as a property to your class, that the updateMyData method can then use, while still having a signature that matches the interface.
Public Class X
Implements InterfaceDataManipulation
Public Sub updateMyData(ByVal x as String) Implements InterfaceDataManipulation.updateMyData
Console.Writeline(x)
End Sub
End Class
The method signature needs to be appended with the method it is implementing in the interface as show above.