How do I code these generic functions and classes inheritances correctly? (VB .NET) - vb.net

I have a function which I need to call for three different types, with the underlying logic remaining the same for all the different types, so I figured it would be best to write this function using generics.
Here is the basic outline of the classes and functions involved:
'PO Base class'
Public MustInherit Class ProductionOrder
Public MustInherit Class Collection(Of T)
Inherits System.Collections.Generic.Dictionary(Of Long, T)
End Class
'....'
End Class
Public Class ProfileProductionOrder
Inherits ProductionOrder
Public Class Collection
Inherits ProductionOrder.Collection(Of ProfileProductionOrder)
End Class
'....'
End Class
Public Class UnitProductionOrder
Inherits ProductionOrder
Public Class Collection
Inherits ProductionOrder.Collection(Of UnitProductionOrder)
End Class
'....'
End Class
Public Class CrateProductionOrder
Inherits ProductionOrder
Public Class Collection
Inherits ProductionOrder.Collection(Of CrateProductionOrder)
End Class
'....'
End Class
'Generic function, intended to work on profile, unit, and crate production orders.'
'This method resides in the base class of the GUI.'
Protected Sub FillPOCells(Of T As ProductionOrder.Collection(Of ProductionOrder)) _
(ByVal dgv As DataGridView, ByVal ProductionOrders As T)
'...do some stuff'
End Sub
'This function resides in the Profile child GUI class.'
Protected Sub LoadDataGridViewPOs()
Dim dgv As DataGridView
Dim ProductionOrders As ProfileProductionOrder.Collection
'....'
'Fill PO Cells'
FillPOCells(Of ProfileProductionOrder.Collection)(dgv, ProductionOrders)
'....'
End Sub
The ProductionOrder base and child classes compile, as does the FillPOCells function. But when I call FillPOCells inside LoadDataGridViewPOs the compiler complains that "Type argument 'ProfileProductionOrder.Collection' does not inherit from or implement the constraint type 'ProductionOrder.Collection(Of ProductionOrder)'.
Also, here is some explanation about why things are set up this way. My predecessor set up the convention of putting the collection of an object as a subclass within it, so it's easy to refer to it as Obj.Collection. Next, the reason we need three different types of production orders is because they are treated differently and stored in different tables and such on the back end. Lastly, I realize I could implement this fairly easily without getting this particular generic function to work, but I'm looking at this as a learning experience to improve my understanding of generics and OO design.
So the question is, why am I getting that compiler error and how should I change my class and generics design to accomplish what I have in mind?
If you need any further explanation about what I'm trying to do or how I have things set up let me know. The main idea is to have a function that can take a collection who's elements belong to one of the ProductionOrder child classes, and run operations on these elements that only use the functionality held in their ProductionOrder base class (hence why either of the child types is okay to operate on in the function).

'PO Base class'
Public MustInherit Class ProductionOrder(Of T)
Public MustInherit Class Collection
Inherits System.Collections.Generic.Dictionary(Of Long, T)
End Class
'....'
End Class
Public Class ProfileProductionOrder
Inherits ProductionOrder(Of ProfileProductionOrder)
'....'
End Class
Public Class UnitProductionOrder
Inherits ProductionOrder(Of UnitProductionOrder)
'....'
End Class
Public Class CrateProductionOrder
Inherits ProductionOrder(Of CrateProductionOrder)
'....'
End Class
That is a lot simpler according to me.
But I higly doubt you need the CollectionClass.

Related

Why base classes must have default new?

I got this error
https://learn.microsoft.com/en-us/dotnet/visual-basic/misc/bc30387
And I wonder why.
What about if I never want to call parameterless new in both base and derived classes?
I can do that if I don't use inheritance. Why using inheritance means I can no longer do so?
To repeat the issue
What's the explanation? So NOT every classes need parameterless new but classes with inheritance must? That doesn't make sense.
What about if I never call derived class with parameter less constructor. I don't intent for the class to ever be constructed without parameter.
For example, say, I want to create a class without parameterless constructor. I can do that right.
But say I want to split the class into two. Parent and child class. I want BOTH not to ever have parameterless constructor.
It seems that I can't do that can I? If such is the case, can anyone please confirm it.
The link says that if you have an explicit constructor in your base class with parameters and no parameterless one than you cannot leave your derived class without constructor. Because VB.NET cannot create an implicit constructor for derived class.
If you don't write any constructors for both, it is perfectly valid.
public class Base
End Class
Public Class Derived
Inherits Base
End Class
However you cannot declare a derived class without an explicit constructor like below. Because VB.NET cannot determine how to initialize base class.
public class Base
Public sub New(ByVal Item As Integer)
End Sub
End Class
Public Class Derived
Inherits Base
End Class
To overcome this issue you can declare a default constructor on derived class which calls base class constructor with a default value.
public class Base
Public sub New(ByVal Item As Integer)
End Sub
End Class
Public Class Derived
Inherits Base
Public Sub New()
MyBase.New(5)
End Sub
End Class

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.

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

VB.NET inheritance - do all properties in the derived classes have to be declared in the base class?

I'm refactoring, and have run into a roadblock.
Background:
I have a base class and several inherited derived classes. The derived classes don't always need to have the same properties. If any properties are shared among the derived classes, those properties would live at the base class level ('Contents', for example).
Similarly, GoodDocument below has 'GoodThings' but would not want/need to have 'BadThings'.
I want to treat instances of both 'GoodDocument' and 'BadDocument' as type 'Document'
public mustinherit class Document
public property Contents as string
public sub new()...
end class
public class GoodDocument
inherits Document
public property GoodThings as string
public sub new()...
end class
public class BadDocument
inherits Document
public property BadThings as string
public sub new()...
end class
The 'DocumentWriter' class will also have several derived classes: ('GoodDocumentWriter' and 'BadDocumentWriter').
I need to pass around the DocumentWriter.Doc as a 'Document' to a number of other places in the code. Doc.GoodThings would only be called from within an instance of either 'GoodDocument' or 'GoodDocumentWriter'.
public mustinherit class DocumentWriter
public property Doc as Document
public sub new()...
end class
public class GoodDocumentWriter
inherits DocumentWriter
public sub new
mybase.Doc = new GoodDocument
end sub
end class
public class BadDocumentWriter
inherits DocumentWriter
public sub new
mybase.Doc = new BadDocument
end sub
end class
Question:
Is there a design pattern that allows for derived classes to have members that don't exist at the base class level?
Do all properties have to live at the base class level?
Revised
I was trying to be brief with my initial question and I made the mistake of over simplifying the situation. In short, I did realize that it should be possible to have different properties on each of the derived classes. (I typed that in a tongue-in-cheek manor and didn't mean to keep it in the final post).
I realize now that the problem that I was experiencing was really symptomatic of a larger issue which needed addressing.
It appears that I was encountering compiler complaints that could be corrected by further refactoring and looser coupling. While others answered the basic question that I posed, Ryan Gross' example really helped kick start some new ideas.
Thanks!
What you should do in this case is define the operations that can be performed on instances of Document in an interface. In your case maybe there is a WriteThings operation, so you would have:
public interface Writeable {
public sub WriteThings();
}
Then in your derived classes you would implement the method to utilize the internal data of the class. For example:
public mustinherit class Document implements Writeable
public property Contents as string
public sub new()...
public sub WriteThings();
end class
public class GoodDocument
inherits Document
public property GoodThings as string
public sub new()...
public sub WriteThings()
//Do something with GoodThings
end sub
end class
public class BadDocument
inherits Document
public property BadThings as string
public sub WriteThings()
//Do something with BadThings
end sub
public sub new()...
end class
Finally, client code that needs to call WriteThings accesses it through an interface:
public mustinherit class DocumentWriter
public property Doc as Writable
public sub new()...
public sub PerformWrite()
Doc.WriteThings();
end sub
end class
It is generally not a good idea to build several parallel class hierarchies. In this case, one DocumentWriter class should be able to write any class that implements Writeable by invoking its WriteThings method.
If all the properties live at the base class level, then I'm not sure what the point of a derived class would be. :) You'd be able to do everything with the base class.
So, yes. If something is applicable only to GoodDocument and not to Document, then it should be in GoodDocument.
To answer your question specifically:
Yes, you just create multiple layers in the inheritance hierarchy: You have a base class, and then many two “branches” (good and bad, to use your terminology). Any properties that are only relevant to either branch, you declare in the class that inherits from the base class. Those properties will only be visible to that class and any classes inheriting from it.
No, properties can be declared anywhere within your inheritance hierarchy.

Type parameters cannot be used as qualifiers

VB.Net2005
Simplified Code:
MustInherit Class InnerBase(Of Inheritor)
End Class
MustInherit Class OuterBase(Of Inheritor)
Class Inner
Inherits InnerBase(Of Inner)
End Class
End Class
Class ChildClass
Inherits OuterBase(Of ChildClass)
End Class
Class ChildClassTwo
Inherits OuterBase(Of ChildClassTwo)
End Class
MustInherit Class CollectionClass(Of _
Inheritor As CollectionClass(Of Inheritor, Member), _
Member As OuterBase(Of Member))
Dim fails As Member.Inner ' Type parameter cannot be used as qualifier
Dim works As New ChildClass.Inner
Dim failsAsExpected As ChildClassTwo.Inner = works ' type conversion failure
End Class
The error message on the "fails" line is in the subject, and "Member.Inner" is highlighted. Incidentally, the same error occurs with trying to call a shared method of OuterBase.
The "works" line works, but there are a dozen (and counting) ChildClass classes in real life.
The "failsAsExpected" line is there to show that, with generics, each ChildClass has its own distinct Inner class.
My question: is there a way to get a variable, in class CollectionClass, defined as type Member.Inner? what's the critical difference that the compiler can't follow?
(I was eventually able to generate an object by creating a dummy object of type param and calling a method defined in OuterBase. Not the cleanest approach.)
Edit 2008/12/2 altered code to make the two "base" classes generic.
Dim succeeds as OuterBase.Inner
.net does not have C++'s combination of template classes and typedefs, which means what you are trying to do is not possible, nor does it even make sense in .net.
ChildClass.Inner and SomeOtherChildClass.Inner are the same type. Here's a short but complete program to demonstrate:
Imports System
MustInherit Class InnerBase
End Class
MustInherit Class OuterBase
Class Inner
Inherits InnerBase
End Class
End Class
Class ChildClass
Inherits OuterBase
End Class
Class OtherChildClass
Inherits OuterBase
End Class
Class Test
Shared Sub Main()
Dim x as new ChildClass.Inner
Dim y as new OtherChildClass.Inner
Console.WriteLine(x.GetType())
Console.WriteLine(y.GetType())
End Sub
End Class
The output is:
OuterBase+Inner
OuterBase+Inner
What were you trying to achieve by using "parameterised" nested classes? I suspect that either it wouldn't work how you'd want it to, or you can achieve it just by using OuterBase.Inner to start with.
Now if each of your child classes were declaring their own nested class, that would be a different situation - and one which generics wouldn't help you with.