VB Inheritance, shared members

[ASB]

Am I just going mad again ???

I have a must inherit base class (Service) and two implementations (Imp1, Imp2). Everything is shared.

I had rather hoped that inheriting said base class would cause Imp1 and Imp2 to extend it independantly. They don't.

Why. I mean if it were instances it wouldn't be true. Seems a bit weird (probably serves me right for using VB.... )

Example:-

Public MustInherit Class Service
Private Shared s_objLogger As aaLogger
Private Shared s_blnSimulated As Boolean

Friend Shared Sub Init(ByVal tag As String)
Dim strTagLog As String = "aaa." & tag

'Create the logger
s_objLogger = new aaLogger(strTagLog)

'Extract whether we are real or simulated.
s_blnSimulated = GetSetting.Simulated(tag)
End Sub

Shared ReadOnly Property Simulated() As Boolean
Get
Simulated = s_blnSimulated
End Get
End Property

Shared ReadOnly Property Logger() As aaLogger
Get
Logger = s_objLogger
End Get
End Property

End Class

And a concrete class....

Public Class Imp1
Inherits Service
Const S_TAG As String = "aa"

Shared Sub New()
Service.Init(S_TAG)
End Sub

Shared Function SomeFunc() As Integer
End Function
end class

And another

Public Class Imp2
Inherits Service
Const S_TAG As String = "bb"

Shared Sub New()
Service.Init(S_TAG)
End Sub

Shared Function SomeFunc() As Integer
End Function
end class

......

imp1.somemethod
imp2.somemethod

if imp1.logger = imp2.logger print "bugger"

 

[dotnetter]

Not sure if I understand what you are trying to acheive.

BUT static class members are created once on the heap so
evaluating a static method or property on a class would point to the same thing in memory?

 

[ASB]

Not sure if I understand what you are trying to acheive.

Well I have a bunch of classes (which actually all just wrap some external APIs). However they flow naturally to a base class which also enables general logging etc and another bunch of stuff which they all want to do in exactly the same way. Thus seems like a natural candidate for a base class and inheritance.

Indeed if the members were all instance members it would all be fine. (No I am not going to make them instance members I need them to be shared for other reasons )

BUT static class members are created on the heap not the stack so
evaluating a static method on a class would point to the same thing?

This just seems wrong (but it's obviously the way it is).

Module Module1

Sub Main()
Imp1.a = 3
Imp2.a = 4

'Seem wrong that both these values are 4.
Debug.WriteLine("imp1.a " & Imp1.a & " imp2.a " & Imp2.a)
End Sub

End Module

Public MustInherit Class BaseCrap
Public Shared a As Integer
End Class

Public Class Imp1
Inherits BaseCrap
End Class

Public Class Imp2
Inherits BaseCrap
End Class

 

[dotnetter]

The thing is if you have an Inheritable class called MyClass with Shared members, those members belong to the TYPE MyClass, if you access those members without an instance it will use the TYPE method which only has once instance on the heap.

If you create an instance of MyClass and access the methods through the instance then you will have 2 different copies of the members on the heap.

Maybe look at implementing a Class Factory pattern, like having a static singleton class that returns instances of your base class dependent on which type you need?

 

[ASB]

Yes, I see what the problem is. It just seems a bit weird that that's the way it is - i.e. it didn't meet my expectations .

I had naiively assumed that the type inheriting from a base class would inherit the base members - clearly not the case.

Anyway, bugger it. I just won't bother inheriting, it's time for a utility class.

 

[Magnus]

...

I had naiively assumed that the type inheriting from a base class would inherit the base members - clearly not the case.

...

Yes it is. It does inherit the base member and its characteristics. The member is shared (or static in C++/C# parlance) by all objects of its type, why on earth would a derived class change the semantics? If you want a member of a derived class to be shared (static) uniquely amongst other objects of the same derived class, you need to define it in each derived class.

If you had it your way, what would happen if you had a reference or pointer to a base class representation which expected to be accessing the shared member of the base class? Things would get screwy.

By the way, you don't need some new utility class. Just define an accessor (i.e. property) in the base class (in C++ terms, a pure virtual function -- is that 'must inherit' in VB.NET? I don't even know what the term is off the top of my head in C#, which is pretty embarrassing since I'm passing myself off as a C# programmer these days), which forces you to define the same accessor (or property) in every class you derive, and in that accessor define a shared (or static) member of the derived class.

Or, if you don't mind the overhead, instead of a simple shared member in the base class, define a shared dictionary which maps from the most-derived class name to the shared object you want to share between every instance of each derived class.

HTH

 

[dotnetter]

Yeah virtual methods are 'virtual' in C# and 'MustInherit' in VB