I understand the concept of interfaces, however I often find it difficult to find practical examples of how to use them. I have produced the following code:
Public MustInherit Class Deletion2
Implements DeletionInterface2
Public MustOverride Function Delete() As String Implements DeletionInterface2.Delete
Public Function CheckDate() As Boolean Implements DeletionInterface2.CheckDate
Return True
End Function
End Class
Public Class System1Delete
Inherits Deletion2
Implements DeletionInterface2
Overrides Function Delete() As String
Return "System 1 Deleted"
End Function
End Class
Public Class System2Delete
Inherits Deletion2
Implements DeletionInterface2
Overrides Function Delete() As String
Return "System 2 Deleted"
End Function
End Class
Public Interface DeletionInterface2
Function CheckDate() As Boolean
Function Delete() As String
End Interface
Public Class Form1
Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim IDeletion As DeletionInterface2
IDeletion = New System1Delete
IDeletion.CheckDate()
IDeletion.Delete()
IDeletion = Nothing
IDeletion = New System2Delete
IDeletion.CheckDate()
IDeletion.Delete()
IDeletion = Nothing
End Sub
In the example above (in page load) I have used a reference to an interface to create an instance of an object, but I do not understand the true benefit of this.
The benefit of using an abstraction like an interface (or a MustInherit class) is that you can treat any object that implements the interface the same exact way.
For example, the System.Data namespace uses many such abstraction, meaning that implementing the different data providers is easier and since the core is using these abstractions, it doesn't need to change as new implementations are added (things about all the different providers, built in and third party - SQL Server, Oracle, PostGresSQL, MySQL etc...).
Related
I'm trying to centralize all formatting and conversion rule in a single class especific. Using the interface INotifyRead(Of T As Class). When I implement the methods BeforeRead/AfterRead throws an exception: Unable to cast object of type 'Especific' to type 'FileHelpers.Events.INotifyRead`1[System.Object]'.
Below my code.
Using engine As New MultiRecordEngine(New RecordTypeSelector(AddressOf CifraRecordTypeSelector),
GetType(RemessaRegistroCliente),
GetType(RemessaRegistroContrato))
Dim records = engine.ReadFile(_camArquivo)
End Using
Public NotInheritable Class RemessaRegistroCliente
Implements INotifyRead(Of RemessaRegistroCliente)
Public Sub AfterRead(e As AfterReadEventArgs(Of RemessaRegistroCliente)) Implements INotifyRead(Of RemessaRegistroCliente).AfterRead
End Sub
Public Sub BeforeRead(e As BeforeReadEventArgs(Of RemessaRegistroCliente)) Implements INotifyRead(Of RemessaRegistroCliente).BeforeRead
End Sub
End Class
Public NotInheritable Class RemessaRegistroContrato
Implements INotifyRead(Of RemessaRegistroContrato)
Public Sub AfterRead(e As AfterReadEventArgs(Of RemessaRegistroContrato)) Implements INotifyRead(Of RemessaRegistroContrato).AfterRead
End Sub
Public Sub BeforeRead(e As BeforeReadEventArgs(Of RemessaRegistroContrato)) Implements INotifyRead(Of RemessaRegistroContrato).BeforeRead
End Sub
End Class
Since MultiRecordEngine has no generic version, you cannot implement the generic INotifyRead(Of T) to handle events. Instead, assign delegates to the engine.
Sub Main()
Using engine As New MultiRecordEngine(New RecordTypeSelector(AddressOf CifraRecordTypeSelector),
GetType(RemessaRegistroCliente),
GetType(RemessaRegistroContrato))
AddHandler engine.BeforeReadRecord, AddressOf BeforeReadRecordHandler
End Using
End Sub
Private Sub BeforeReadRecordHandler(ByVal engine As EngineBase, ByVal e As BeforeReadEventArgs(Of Object))
End Sub
You'll also need to modify your classes to remove the generic interfaces:
Public NotInheritable Class RemessaRegistroCliente
'your fields
End Class
Public NotInheritable Class RemessaRegistroContrato
'your fields
End Class
is it possible to extend different classes with the same generic class?
I tried something like this:
Public Class A
Public Sub TestA()
Debug.Print("Test A")
End Sub
End Class
Public Class B(Of T)
Public Sub TestB()
Debug.Print("Test B")
End Sub
End Class
Public Class C
Inherits B(Of A)
Public Sub TestC()
TestA() '**<-- Thows error 'is not declared'**
TestB()
Debug.Print("Test C")
End Sub
End Class
I basicly have some usercontrols, which derive from Combobox or Textbox and i'd like both to implement some functions(and interfaces) that are defined in a base class. In C++ i'd do it with multi inheritance.
is it possible to extend different classes with the same generic class?
Generics isn't some kind of "workaround" for a lack of multiple inheritance, no. Your class C doesn't derive from A - it just means that the T in B(Of T) would be A in the context of C.
Which instance of A would you expect TestA() to be called on? Creating an instance of C certainly doesn't create an instance of A...
The fact that B(Of T) doesn't use T anywhere should be a warning signal - types which are generic but never use their generic type parameters are generally problematic.
It's hard to know exactly how to help you solve your real problem without more details, but you can't add a common base class in like this, when you also need to derive from other types which aren't under your control.
Perhaps extension methods would help?
You could make both your Combobox and your Textbox classes implement the same interface.
Then you could define extension methods on that interface class.
Thanks to your hint i got this working with extentions
Public Class Form1
Public Interface IA
Property val As String
End Interface
Public Class A
Public Sub test()
Debug.Print("test")
End Sub
End Class
Public Class C
Inherits A
Implements IA
Public Property val As String Implements IA.val
Public Sub TestC()
val = "testxxx"
TestA()
test()
End Sub
End Class
Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load
Dim ct As New C
ct.TestC()
End Sub
End Class
Module TestModule
<Extension()>
Public Sub TestA(ByVal pvIA As IA)
Debug.Print(pvIA.val)
End Sub
End Module
This way every class can implement it's own 'parent' (like A here) and i don't need to implement the function TestA for every class.
thank you
While researching Assembly.GetInterfaces(), I found the method was a MustOverride method. Which in my understanding means it has no default action to derived classes. Its just a signature basically, an abstract method. Yet, I can still use it on a type and it will return all implemented interfaces without writing any code for the MustOverride method.
Where is this code that has slipped into the MustOverride method? Have I somehow indirectly overridden it just simply by calling the method on a created type?
This question is purely on the basis of study and discovery, I am not trying to do anything other than understand the confines of the language.
Here is the code I used:
Public Class Form1
Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim t As Type
Debug.WriteLine(GetType(Integer))
t = GetType(Integer)
Dim interfaceArr As Type() = t.GetInterfaces
For i As Integer = 0 To interfaceArr.Length - 1
Debug.WriteLine(interfaceArr(i))
Next
End Sub
End Class
Output Is:
System.IComparable
System.IFormattable
System.IConvertible
System.IComparable 1[System.Int32]
System.IEquatable 1[System.Int32]
Any MustOverride method can always be called on an instance of any type because you couldn't possibly create an instance of a class unless the class provides concrete implementations of all of the MustOverride methods. In this case, your confusion is that you are assuming that the t variable is referencing a Type object, but that is not the case. Since Type is a MustInherit class, it's impossible to ever instantiate an object of that type directly. You could only ever instantiate an object of a class that derives from Type. If you use the debugger to inspect the T variable, you will notice that it is actually referencing an instance of the RuntimeType class, which is an undocumented class which obviously derives from Type.
For instance, consider this example, which duplicates the behavior:
Public Class Form1
Public MustInherit Class BaseClass
Public MustOverride Function GetGreeting() As String
End Class
Public Class DerivedClass
Inherits BaseClass
Public Overrides Function GetGreeting() As String
Return "Hello world"
End Function
End Class
Public Function GetInstance() As BaseClass
Return New DerivedClass()
End Function
Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim t As BaseClass = GetInstance()
Debug.WriteLine(t.GetGreeting())
End Sub
End Class
As you can see, the t variable is of the BaseClass type, but it's actually referencing a DerivedClass object. Therefore, even though the BaseClass class defines the method as MustOverride, you can still call it because the actual type of the object does implement it.
Ok, so I was playing around with Ninject, a "Service Layer" and a "Repository Layer".
I built a simple console application to to play around, this is what I came up with:
Imports Ninject
Module Module1
Sub Main()
Dim Kernel As IKernel = New StandardKernel(New CustomerModule)
Dim Service = Kernel.Get(Of CustomerService)()
Console.WriteLine(Service.GetCustomerByID(1).Name)
Console.Read()
End Sub
End Module
#Region "Services"
Public Class CustomerService
Private _Repository As ICustomerRepository
<Inject()> _
Public Sub New(ByVal Repository As ICustomerRepository)
_Repository = Repository
End Sub
Public Function GetCustomerByID(ByVal ID As Integer) As Customer
Return _Repository.GetByID(ID)
End Function
End Class
#End Region
#Region "Repositories"
Public Interface IRepository(Of T)
Function Query(ByVal Predicate As Expressions.Expression(Of Func(Of T, Boolean))) As IQueryable(Of T)
Function GetByID(ByVal ID As Integer) As T
End Interface
Public Interface ICustomerRepository
Inherits IRepository(Of Customer)
End Interface
Public Class CustomerRepository
Implements ICustomerRepository
Public Function GetByID(ByVal ID As Integer) As Customer Implements IRepository(Of Customer).GetByID
Return New Customer With {.ID = ID, .Name = "Sam Striano"}
End Function
Public Function Query(ByVal Predicate As System.Linq.Expressions.Expression(Of System.Func(Of Customer, Boolean))) As System.Linq.IQueryable(Of Customer) Implements IRepository(Of Customer).Query
Return Nothing
End Function
End Class
#End Region
#Region "Domain Objects"
Public Class Customer
Public Property ID As Integer
Public Property Name As String
End Class
#End Region
#Region "Ninject Modules"
Public Class CustomerModule
Inherits Modules.NinjectModule
Public Overrides Sub Load()
Bind(Of ICustomerRepository).To(Of CustomerRepository)()
End Sub
End Class
#End Region
My question, or I guess my lack of understanding, lies in Main() method of the module:
Sub Main()
Dim Kernel As IKernel = New StandardKernel(New CustomerModule)
Dim Service = Kernel.Get(Of CustomerService)()
Console.WriteLine(Service.GetCustomerByID(710615).Name)
Console.Read()
End Sub
Why not just do this:
Sub Main()
Dim Service = New CustomerService(New CustomerRepository)
Console.WriteLine(Service.GetCustomerByID(710615).Name)
Console.Read()
End Sub
Basically, you are asking why you should use a DI Container instead of Pure DI.
DI is really just a set of principles and patterns that enable loose coupling. You can use those patterns to compose an application irrespective of any particular container.
However, as an application grows in complexity, and particularly when you need to manage differing lifestyles of your components, a DI Container is an excellent tool that addresses many issues that you'd otherwise have to address manually.
Dependency injection lets you decouple specific implementations of objects from their interfaces. It is difficult to justify in most of the small examples out there, but for larger systems it can be a life-saver. It can also help you to isolate your objects in unit tests.
For example, if you wanted to write tests for your CustomerService class, you could easily inject a MockRepository instead of CustomerRepository. This would let you test CustomerService without also testing CustomerRepository.
Outside of unit testing, I think the easiest example to visualize might be if you were writing a data access module for your application. You might want to support SQL Server and MySQL. You would then create Interfaces for your data access objects and create specific implementations of them for both database systems. Those implementations could be injected at runtime, thusly:
Function Setup(ByVal dbType As String) As IKernel
Dim dbModule As NinjectModule
If dbType = "SQL Server" Then
dbModule = New SQLServerModule
Else If dbType = "MySQL" Then
dbModule = New MySQLModule
End If
Return New StandardKernel(dbModule)
End Function
This also enables you to add support for other databases in the future, isolating the implementation details from the rest of the application.
I have two classes:
Public Class Subscribing
Private _subscribingObjects As IList(Of String)
Public Sub Add(ByVal obj As SubscribeObject)
'...code...'
End Sub
Public Sub Remove(ByVal index As Integer)
'...code...'
End Sub
End Class
Public Class Providing
Private _providingObjects As IList(Of String)
Public Sub Add(ByVal obj As ProvideObject)
'...code...'
End Sub
Public Sub Remove(ByVal index As Integer)
'...code...'
End Sub
End Class
Is there a more elegant way to add do this? One class would suffice, but since the Add methods have different arguments, then one really wouldn't work.
Any help would be appreciated.
this?
Public Class SubscribingProviding(Of t)
Private _subscribingObjects As IList(Of String)
Public Sub Add(ByVal obj As t)
'...code...'
End Sub
Public Sub Remove(ByVal index As Integer)
'...code...'
End Sub
End Class
Your add functions should be fine. As long as you have different variable types being passed in you can have the function names be the same. Your remove Subs will not be allowed in the same class because it is using the same parameter Integer.
Eh.. probably not. They are different enough that you cant even Interface them.
I personally wouldn't mix the two responsibilities (of subscribing and providing) in one class. The classes themselves can easily be simplified by just inheriting from List(Of T)
Public Class Subscribing
Inherits List(Of SubscribeObject)
End Class
Public Class Providing
Inherits List(Of ProvideObject)
End Class
If you really want to get down to one class and make sure that it can only accept SubscribeObject and ProvideObject respectively, implement a common interface in both SubscribeObject and ProvideObject. Then create a generic class that accepts the interface:
' Common interface '
Public Interface ISubscribeProvideObject
End Interface
' SubscribeObject and ProvideObject both implementing the common interface '
Public Class SubscribeObject
Implements ISubscribeProvideObject
'...'
End Class
Public Class ProvideObject
Implements ISubscribeProvideObject
'...'
End Class
' Generic class accepting both types '
Public Class SubscribingProviding(Of T As ISubscribeProvideObject)
Inherits List(Of T)
'... Add() and Remove() methods only needed if custom logic applies ...'
End Class