Inheritance question…

Ray Cassick

For the sake of this question I will use the old animal example that gets used in all the basic inheritance books.. Lets say that I have a base class called CAnimal and I inherit it to another class called CDog Form within CAnimal, is there a way that I can get the type that is the parent (CDog in this case)? I would like to perform some processing differently in the base class depending on what subclass has called it. If there some way I can do something like Me.Parrent.GetType("Cdog")?

Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things."

Richard Deeming

You can use TypeOf(Me):

Public Class Animal
Public Sub Bark()
If TypeOf(Me) Is Dog Then
Console.WriteLine("Bark!")
Else
Console.WriteLine("I can't bark!")
End If
End Sub
End Class

Public Class Dog : Inherits Animal

End Class

However, this is very bad design. You should provide generic functionality in the base class, and then override or extend that functionality in the derived class:

Public Class Animal
Public Overridable Sub Bark()
Console.WriteLine("I can't bark!")
End Sub
End Class

Public Class Dog : Inherits Animal
Public Overrides Sub Bark()
Console.WriteLine("Bark!")
End Sub
End Class

If you can't provide generic functionality in the base class, you can make the method abstract (MustOverride):

Public MustInherit Class Animal
Public MustOverride Sub Bark()
End Class

Public Class Dog : Animal
Public Overrides Sub Bark()
Console.WriteLine("Bark!")
End Sub
End Class

If the functionality is not applicable to all classes derived from the base class, consider removing it from the base class. For example, you wouldn't want your Cat class to have a Bark method!

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

mikasa

Actually, a better way would be to provide a ReadOnly Property called "Type". You can have this Property return an Enum (if you know how many ClassTypes you will have) or just a String if you Like. You could then Override the Property in the Derived Classes so that they can Return what Type of Class they are as well. I find that Enums are great! Especially if you are allowing other Developers to use your Classes (since they don't know what Types to expect, Enums help a lot!). 'Base Class Public Class Animal 'Enum Public Enum AnimalTypes Animal Dog Cat Bird End Enum Public Overridable ReadOnly Property Type() As String Get Return "Animal" End Get End Property Public Overridable ReadOnly Property Type2() As AnimalTypes Get Return Animal End Get End Property End Class 'Derived Class Public Class Dog:Inherits Animal Public Overrides ReadOnly Property Type() As String Get Return "Dog" End Get End Property Public Overrides ReadOnly Property Type2() As AnimalTypes Get Return Dog End Get End Property End Class

Ray Cassick

I am taking a good look at what both of you have said... I can understand why Richard Demming thinks that this would be very bad design, but in my defense I had a specific reason for doing it. 1 - The base class provides all but a very little part of the functionality of the library. 2 - The base library only exposes 3 classes that derive from the base class, and these classes can not be inherited from any further. 3 - The base class implementations of each method very only slightly in how certain database connections are handled based upon what class has inherited the base class. 4 - The bass class implementations are not really overridden. The derived class calls the base class implementations by using MyBase.Methodname. I considered using an interface and some helper functions here in place of inheritance, but because the implementations are so close I was seeing the possibility for a lot of duplicated code. As for your suggestions about using Enums, I totally agree :) I use enums wherever I can. In fact I have been accused of their overuse if you can imagine such a thing. I figure that, besides the other benefits, enums offer a way for the user to enter in parameters in a way that removes a large likelihood of error. They can't just make up values that way, but have to pick form a list.

Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things."

Ray Cassick

I want to thank both of you for your comments on this… After taking a long hard look at the architecture I had originally selected I finally decided to refactor things a bit and moved away from the inheritance aspect since there were some apparent, albeit subtle, differences in the implementation between what each child class needed. I ended up using an interface style and backed it up by using come common helper functions behind the scenes. I even ended up lowering my LOC count by about 30% and dropping the complexity of the design a significant amount because of it. I also noticed that the problem with my chosen implementation seemed to become apparent when I started the steps of documenting the class with XML docs. There were things showing up in the docs (I am using Ndoc) and things exposed to the outside world that I did not want exposed. The process of building the documentation for the library pointed that out very quickly. Thanks again…

Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things."