How to hide base class member variable in derived class (w/oshadows)?

  • Thread starter Thread starter Joe Duchtel
  • Start date Start date
J

Joe Duchtel

Hello -

I have a base class that has some member variables I do not want to be
inherited or visible by any instance of that derived class.

Class cBase
Public mVariable As String
...

Class cDerived
Inherits cBase

Hide mVariable ' <<< Private Shadows mVariable As ... is not
working

The problem if I use Private Shadows in the derived class is that an
instance will still show the variable in the base class:
Dim lDummy As New cDerived
lDummy.mVariable will be mVariable of cBase.

I tried Protected in cBase but then I cannot see mVariable in other
derived classes anymore.

I realize that there is no data encapsulation in my example but there
is a (legacy) reason for that. I would have the same problem if I
were to use an accessor or Property.

Is there any mechanism in VB.NET that will allow me to completely hide
a member variable of the base class in a particular derived class?

Thanks,
Joe
 
Joe said:
Hello -

I have a base class that has some member variables I do not want to be
inherited or visible by any instance of that derived class.


You inherit everything from the base class.

Class cBase
Public mVariable As String
...

Class cDerived
Inherits cBase

Hide mVariable ' <<< Private Shadows mVariable As ... is not
working

The problem if I use Private Shadows in the derived class is that an
instance will still show the variable in the base class:
Dim lDummy As New cDerived
lDummy.mVariable will be mVariable of cBase.

I tried Protected in cBase but then I cannot see mVariable in other
derived classes anymore.

Really? This works:

Class cBase
Protected mVariable As String
End Class

Class cDerived
Inherits cBase
Sub sdfsdf()
mVariable = "sdf" 'works
End Sub
End Class

I realize that there is no data encapsulation in my example but there
is a (legacy) reason for that. I would have the same problem if I
were to use an accessor or Property.

Is there any mechanism in VB.NET that will allow me to completely hide
a member variable of the base class in a particular derived class?

Not that I know of.



Armin
 
You inherit everything from the base class.









Really? This works:

   Class cBase
      Protected mVariable As String
   End Class

   Class cDerived
      Inherits cBase
      Sub sdfsdf()
         mVariable = "sdf"    'works
      End Sub
   End Class



Not that I know of.

Armin- Hide quoted text -

- Show quoted text -

Hello -

I understand inheritance and how Protected works but I was looking for
something outside of the derived class. Here is a full example of
what I'm trying to do written out ...

Module Test
Public Class cBase
Public mA As String = String.Empty
Public mB As String = String.Empty
End Class

Public Class cDerivedA
Inherits cBase

Private Shadows mA As String = String.Empty
End Class

Public Class cDerivedB
Inherits cBase
End Class

Sub Main()
Dim lDerivedAInstance As New cDerivedA
lDerivedAInstance.mA = "THIS SHOULD NOT WORK!"
lDerivedAInstance.mB = "OK"

Dim lDerivedBInstance As New cDerivedB
lDerivedAInstance.mA = "OK"
lDerivedAInstance.mA = "OK"
End Sub
End Module

The lDerivedAInstance.mA = "..." only works because it accesses the
instance of mA in cBase. If I protect that in cBase, I cannot access
it through an instance of cDerivedB anymore.

Thanks!
Joe
 
Joe said:
I understand inheritance and how Protected works but I was looking for
something outside of the derived class.

I know, but you wrote

I wasn't able to repro this problem. Anyway, it's not possible what you're
trying to do.

But why do you want to do it? If every car (base class) has wheels and an
engine, a BMW (derived class) doesn't have an engine only.


Armin
 
I know, but you wrote


I wasn't able to repro this problem. Anyway, it's not possible what you're
trying to do.

But why do you want to do it? If every car (base class) has wheels and an
engine, a BMW (derived class) doesn't have an engine only.

Armin

Hello -

Sorry ... I guess I was not very clear in that first paragraph. I
figured that this is not really supported.

I understand that this idea defies OOP to some extent but I have to
deal with some legacy code that I cannot break to make it work in a
better way.

Thanks!
Joe
 
More specifically :

    Public Class cBase
        Public mA As String = String.Empty
        Public mB As String = String.Empty
    End Class
    Interface ICDerivedA
        Property mb() As String
    End Interface

    Public Class cDerivedA
        Inherits cBase
        Implements ICDerivedA
        Private Shadows mA As String = String.Empty
        Public Shadows Property mB() As String Implements ICDerivedA.mb
            Get
                Return MyBase.mB
            End Get
            Set(ByVal value As String)
                MyBase.mB = value
            End Set
        End Property
    End Class

    Public Class cDerivedB
        Inherits cBase
    End Class

    Sub Main()
        Dim lDerivedAInstance As ICDerivedA = New cDerivedA
        lDerivedAInstance.mA = "THIS SHOULD NOT WORK!" ' DOESN'T COMPILE
        lDerivedAInstance.mb = "OK"

        Dim lDerivedBInstance As New cDerivedB
        lDerivedBInstance.mA = "OK"
        lDerivedBInstance.mA = "OK"
    End Sub

But I'm not sure if it wouldn't break your existing code. Also you could
reverse the inheritance relation (as in your sample cBase handles all what
cDerivedA handles not the other way round) but once again we don't know how
it would impact your existing code...

Or make them properties (is this possible) and throw an exception to at
least prevent what you don't want at runtime or even add an "obsolete"
attribute to see if it prevents compiling.

At some point you'll have to weight living with those workarounds agaisnt
changing the design (this is not VB.NET legacy code ?)...

--
Patrice

"Patrice" <http://www.chez.com/scribe/> a écrit dans le message de groupe de
discussion : [email protected]...





- Show quoted text -

Hello -

This is actually pretty slick. I have never used the Interface before
but it works beautifully. Now I'll just have to figure out how to
make it work without breaking some of the legacy code.

I agree that at some point you just have to move forward but the
impact is huge ...

Thank a lot!
Joe
 
Back
Top