By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,054 Members | 902 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,054 IT Pros & Developers. It's quick & easy.

OOP question

P: n/a
I get the jist of this Inheritance stuff, I think, I'm just looking to
understand better...

I created a MustInherit base class with a constructor that had arguments.
Within the constructor method, the param values were mapped (or saved to)
module level PRIVATE variables. I decided on PRIVATE module variables over
PROTECTED because I reasoned that if I NEEDED to expose the module level
variables to the classes that inherited from my base class, I could do so
later. Until then, they were private.

I then created a subclass that had a constructor of its own. On this
constructor, I called, MyBase.New, which passed the param of the subclass's
constructor to the base class, so the base class could initialize itself.

One drawback of passing the sub class's constructor params to the base
class, I found, is this: The first line of the sub class had to be
MyBase.New, which meant, I could not add logic prior to this call to alter
or derive the parameter values before I pass them to the base class
constructor. This is probably atypical, although I got around the issue by
using a complex IIF statment within the My.New all.

My question is this: Someone suggested to me that I should have classed the
module level variables of my base class as protected and directly
initiatlized them from the sub class.

Is there a reason why one approach would be distinctively bette rthan the
other?
Nov 21 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a

"Chad" <ch**************@unisys.com> wrote in message
news:di**********@trsvr.tr.unisys.com...
I get the jist of this Inheritance stuff, I think, I'm just looking to
understand better...

I created a MustInherit base class with a constructor that had arguments.
Within the constructor method, the param values were mapped (or saved to)
module level PRIVATE variables. I decided on PRIVATE module variables over
PROTECTED because I reasoned that if I NEEDED to expose the module level
variables to the classes that inherited from my base class, I could do so
later. Until then, they were private.

I then created a subclass that had a constructor of its own. On this
constructor, I called, MyBase.New, which passed the param of the
subclass's constructor to the base class, so the base class could
initialize itself.

One drawback of passing the sub class's constructor params to the base
class, I found, is this: The first line of the sub class had to be
MyBase.New, which meant, I could not add logic prior to this call to alter
or derive the parameter values before I pass them to the base class
constructor. This is probably atypical, although I got around the issue by
using a complex IIF statment within the My.New all.
This is very common, and the typical solution is to use a private shared
(static in C#) function to which accepts some of the subclass's constructor
arguments and returns a base class argument.

Public Class Foo
Public Sub New(ByVal i As Integer)
End Sub
End Class
Public Class Bar
Inherits Foo
Private Shared Function GetI(ByVal s As String) As Integer
Return 1
End Function
Public Sub New(ByVal s As String)
MyBase.New(GetI(s))
End Sub
End Class

My question is this: Someone suggested to me that I should have classed
the module level variables of my base class as protected and directly
initiatlized them from the sub class.

Is there a reason why one approach would be distinctively bette rthan the
other?


Yes. You had it right. If, at the base class level, you can determine that
you need to initialize the object to a valid state, then you should have a
constructor. If you make the variables protected and rely on the subclass
to set them you have introduced an undocumented operational requirement for
subclasses. (That's a bad thing.)

David
Nov 21 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.