views:

235

answers:

3

I have 2 classes, a parent and a child.


Class Test
    Private Test_Text

    Private Sub Class_Initialize()  
     Test_Text = "Hello"
    End Sub  

    Private Sub Class_Terminate()   

    End Sub 

    Public Property Get Text
     Text = Test_Text
    End Property

    Public Property Let Text(ByVal strIn)
     Test_Text = strIn
    End Property
End Class

Class SubTest
    Public SubTest_Test 
    Private SubTest_Interger

    Private Sub Class_Initialize()  
     Set SubTest_Test = New Test
    End Sub  

    Private Sub Class_Terminate()   
     Set SubTest_Test = Nothing
    End Sub

    Public Property Get int
     int = SubTest_Integer
    End Property

    Public Property Let int(ByVal intIn)
     SubTest_Integer = intIn
    End Property 
End Class

Because I have made SubTest_Test public I can access it through the child class like this


Set MyTest = New SubTest
MsgBox MyTest.SubTest_Test.Text

Is this acceptable or should I make SubTest_Test private and write properties in the child class to access the parents properties?

Edit: I guess the question should have been, are there any security/usability issues with accessing the parent directly.
The more I think about it the more I think from a usability standpoint, it is better to hide the parent from anyone using the child class. That way when you are creating an object from the child class, you don't have to know anything about the parent class.

+2  A: 

Since this is a HAS-A relationship between your two classes then I think you ought to leave it as is. You don't need to introduce encapsulating code for something that does not need it.

Here is a pseudo-code example:

class Engine
    [method] start()

class Car
    [property] Engine

Ideally you would want to reference Engine as a property of Car like so:

Car.Engine.start()

The alternative would be to write extra code in Car to wrap the methods in Engine. While you can do this it doesn't make much sense as you will be simply writing pass-through methods from Car to Engine.

Andrew Hare
This seems like an argument aginst doing it this way. When I start my car I want more than the engine to start, I wouldn't want to start each system independently. I would want a Car.Start() that starts all of the systems.
Tester101
Nice point! I would agree that Car.Start() would make sense from an organizational standpoint to collect Engine methods into a single place. However the original question was asking whether or not to create 1-to-1 relationships with child class properties mapping directly to the parent's.
Andrew Hare
A: 

I'd say it depends on the number of properties you want to expose. But encapsulation is always a good rule to follow. If Text is the only property you'll be accessing, I'd most likely make SubTest_Test private and wrap the property.

hmcclungiii
+1  A: 

no - this violates the Law of Demeter; rethink the interface - under what circumstances would someone need to access the Text property of the enclosed Test object in a SubTest object? If these situations make sense, you'll need to expose Text as a property in SubTest.

Given the names I would have expected SubTest to inherit from Test and thus automatically expose the Text property, but thankfully I have forgotten VBSCRIPT so I can't remember if it even supports inheritance ;-)

Steven A. Lowe
VBScript does not support inheritance, but by making a Test object in the SubTest object it gains access to the Test objects properties and methods.
Tester101
@[Tester101]: then you'll have to manually expose the pseudo-inherited interface to complete the picture
Steven A. Lowe