-
Nov 18th, 2010, 10:19 AM
#1
Thread Starter
Member
Abstract Classes - vb.net
I have been reading up on Abstract classes and am thinking about utilizing them in an upcoming project.
I would like to know the pros and cons of using abstract classes from someone who has actually used them.
Additionally, I would like to know if the abstract class needs to be in it's own project or if they should be defined in an existing project and used within the application.
Any sharing of this information would be greatly appreciated...
-
Nov 18th, 2010, 10:39 AM
#2
Re: Abstract Classes - vb.net
I'd like to hear your definition of an abstract class, first. I don't think there is just one.
However, talking about where it should be is relatively easy: If you think that you will be creating something that is of sufficient value to you or others that it will be useful in multiple projects, then it should be defined in a dll that can be included into multiple projects. If, on the other hand, the class is so highly specific to a single project that you cannot imagine anybody else ever using it, then it doesn't really make much difference where it is defined.
My usual boring signature: Nothing
-
Nov 18th, 2010, 10:49 AM
#3
Thread Starter
Member
Re: Abstract Classes - vb.net
thank you Shaggy! That makes sense and I appreciate your help.
In regards to my definition of an abstract class.... here is an example of the abstract class that i was reviewing. The following is the "base" code that would apply to the majority of the employees in a company
vb Code:
Public MustInherit Class EmployeeBase Public Property Name() As String Get End Get Set(ByVal Value As String) End Set End Property Public Property DateOfHire() As Date Get End Get Set(ByVal Value As Date) End Set End Property Public Overridable Property RetirementID() As String Get End Get Set(ByVal Value As String) End Set End Property Public MustOverride Function Compensation() As Object End Class
Here is a derived class that would be used for an employee in France:
vb Code:
The derived class EmployeeFrance. Public Class EmployeeFrance Inherits EmployeeBase Public Overrides Function Compensation() As Object ' Implementation of the Compensation method for employees ' in France goes here. End Function End Class
This allows the base code to be used at all times and over-ride any exceptions or parts of the base code that are not needed or overridden for another country.
If there is a better way to share the code, I'm interested. I have a project that I'm trying to streamline that uses HL7 or X12 Standards for EDI processing and thought this might be a great way to standardize yet be flexible enough for any parts of the process that need to be customized....
-
Nov 18th, 2010, 10:55 AM
#4
Re: Abstract Classes - vb.net
Ok, you are using the definition I would have used. It could also be called a pure virtual base class in that it cannot be instantiated on its own, but must be derived. The other alternative to look at is an Interface. Your example would actually make more sense as an interface just because NONE of the methods have bodies. If your abstract base class had a few methods that were implemented in the base, then the interface wouldn't be so good, but if the whole point of the base class is to define a set of methods that the derived classes MUST implement...that's an interface.
My usual boring signature: Nothing
-
Nov 18th, 2010, 11:05 AM
#5
Thread Starter
Member
Re: Abstract Classes - vb.net
I did think about the interface option. but I read somewhere that interfaces can be added to but not subtracted from and so I thought that could be an issue. Is this true?
Could you expand a little on what you mean by NONE of the methods have bodies?
-
Nov 18th, 2010, 11:15 AM
#6
Re: Abstract Classes - vb.net
I would say that what you have heard about interfaces is correct. If you have X methods in an interface, then any class that implements that interface must have all X methods. Those methods don't have to DO anything, but they do have to be present.
As to the part about having a body: In your example, the properties don't have to be overriden. This suggests that the base class properties will actually be fully implemented like so:
Code:
Public Property Name() As String
Get
Return myName
End Get
Set(ByVal Value As String)
myName = Value
End Set
End Property
Now you don't need to override the property in the derived class (you weren't anyways, in your example), and you couldn't do that in an interface.
Clearly there is a time and place for both, but I think you have a good handle on it. In practice, I have always defined my base classes in the same project that houses the derived classes, whether that is in a dll or not. I do recall one case where I put the base class in one dll and derived classes in a different one, but that was specifically to allow for a certain expected use of the various pieces.
My usual boring signature: Nothing
-
Nov 18th, 2010, 12:12 PM
#7
Thread Starter
Member
Re: Abstract Classes - vb.net
Shaggy - you have been very very helpful! Thank you so much!
-
Nov 18th, 2010, 01:26 PM
#8
Re: Abstract Classes - vb.net
One of the things that I like about a base/abstract class is that all common methods and properties which are generic are in the base class while the classes inheriting from the base class are responsible for implementing methods which are different than the base plus the base class enforces the classes which inherit from the base class must implement specific methods.
Example, I read raw data streams (using Aspose PDF library) from PDF files where there are five different structures where each structure has the same elements but the elements are in different locations within the data streams so all logic that is common is in the BaseInvoice class and the child classes need only be responsible for traversing the data stream.
Code:
Public MustInherit Class BaseInvoice
Private mIdentifier As Integer
Public Property Identifier() As Integer
Get
Return mIdentifier
End Get
Set(ByVal value As Integer)
mIdentifier = value
End Set
End Property
…
Public MustOverride Function RetrieveDataStream() As Boolean
End Class
Public Class InvoiceA
Inherits BaseInvoice
Public Overrides Function RetrieveDataStream() As Boolean
End Function
End Class
-
Nov 18th, 2010, 01:40 PM
#9
Re: Abstract Classes - vb.net
I also like runtime polymorphism. I am currently working on a fish hatchery program. Raceways come in various shapes, and can be split in different ways depending on their geometry. Therefore, I created a base raceway class, which has some functionality common to all raceways, then each actual geometry implements the division method, the volume method, and so on. In the program, I just have a list of the base raceway class, and call the methods against that base class. The fact that the class is actually an instance of the derived class means that the method for the derived class is what is actually called, but I only need to deal with it as a base class rather than keeping track of what type it is.
My usual boring signature: Nothing
-
Nov 18th, 2010, 02:46 PM
#10
Thread Starter
Member
Re: Abstract Classes - vb.net
Sounds like great usage and seems pretty slick! Are there any down sides to using abstract classes? Or is it all Good!
-
Nov 18th, 2010, 02:54 PM
#11
Thread Starter
Member
Re: Abstract Classes - vb.net
What I lilked about reading the abstract class, is that the base class can include all default processing. Additional flexibility is provided when defining the default processing when using:
vb Code:
Public Overridable Property RetirementID() as string
When this is used in the base class, as shown above, then it can be overridden in a derived class usage elsewhere. For example, another Class would be a derived class called EmployeeEngland
vb Code:
Public Class EmployeeEngland Inherits EmployeeBase Public Overrides Function Compensation() As Object ' Implementation of the Compensation method for ' employees in England goes here. End Function [B]Public Overrides Property RetirementID() As String ' Implementation of the RetirementID property for ' English employees goes here. Get End Get Set(ByVal Value As String) End Set End Property[/B] End Class
I'm new to .net (an old mainframe programmer) and so I'm really impressed with this!!! Very very cool...
-
Nov 18th, 2010, 03:23 PM
#12
Re: Abstract Classes - vb.net
There are no downsides to abstract base classes inherent in the class itself, except one minor one. There may be a very slight performance penalty to using runtime polymorphism as I am doing, and that performance probably exists as long as you have an abstract base class. However, that performance hit may be exactly Nothing! When this type of thing was first introduced in C/C++, it was at a time when high performance games were written in C. There was some talk that the performance penalty was such that C++ was not suitable for games. Improvements in C++ compiler design removed either all or almost all of the performance penalty (I don't know which, I just heard that it was no longer an issue as of sometime in the mid-90's) and I would expect that VB.NET would have taken advantage of the design understanding gained from early C++ compilers. Therefore, that penalty is little, and is probably nothing at all.
The only other issue is that some people get carried away with inheritance. It is possible to make such a complex, multi-layered, tree of inheritance that it becomes very hard to maintain anything. Some of those trees can be very elegant, which just goes to show that in programming, it is not only God that can make a tree, but when they get that elegant, it might well be the case that only God can UNDERSTAND the tree.
My usual boring signature: Nothing
-
Nov 19th, 2010, 09:56 AM
#13
Thread Starter
Member
Re: Abstract Classes - vb.net
Let's take it a step further....
If I have two abstract classes called Class_1 and Class_2.
Class_1 contains the constructors (external to the application in it's own dll)
Class_2 is now being created and will need the contents of Class_1 in order to execute properly. Therefore it is necessary to have Class 1 passed into the Class_2 in order to work properly.
When creating the DLL for Class 2, I add the reference for Class_1 to the Dll so that the base class pulls in Class_1. The Code would resemble the following:
Code:
Public MustInherit Class Class_2
Inherits Class1
Sub Class2_Body_Interp(ByVal currentRow() As String, ByVal interpClass As Class1)
<Add Contents to print the detail or body of the report>
End Sub
End Class
The above class is now in it's own Dll for use to all applications.
Then to use the above abstract class, We would then need to add the Class_2 reference to the project that wishes to access the abstract class and add the following code in the project.
Code:
Public Class TEST_Abstract
Inherits Class_2
End Class
Is this correct?
-
Nov 19th, 2010, 12:10 PM
#14
Re: Abstract Classes - vb.net
I wouldn't say that it is wrong, but it seems like it might be overly complex. I interpreted what you wrote to mean that Class2 inherits Class1, and that each is defined in its own dll. Then I see a third class that inherits Class2. The only justification I see for having Class1 and Class2 in different dlls is if there might also be a Class3 that also inherits Class1, but doesn't have any relationship to Class2. If that is the case, then your design is reasonable. However, you would also be starting down a slippery slope where every class inherits one or more other classes and no class can ever be changed because they are so interrelated. I get a bit nervous when I have three levels of inheritance (A inherits B which inherits C). At some point, that becomes more headache than help. Still, if the design makes sense, then go for it.
My usual boring signature: Nothing
-
Nov 19th, 2010, 12:52 PM
#15
Thread Starter
Member
Re: Abstract Classes - vb.net
Thanks Shaggy - This is not my project just a scenario to see whether or not I understand the concept.
This inheritance stuff can get ugly! So keeping it simple is best and in this case it would probably be best to combine class 1 and class 2 into one abstract class?
-
Nov 19th, 2010, 01:04 PM
#16
Re: Abstract Classes - vb.net
Unless you specifically need them to be separate, I would combine them.
My usual boring signature: Nothing
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|