nested classes... or something.

  • Thread starter Thread starter nobody
  • Start date Start date
N

nobody

I just tried to do something and realized I'm not sure of the proper (if
there *IS* a proper) way to do it. I'm designing a class with a lot a
methods/properties. I would like to group some of them so you access them
like MyObject.Commands.blah1, MyObject.Commands.blah2, etc... So some of
the methods are grouped under "Commands".

My first thought was a nested class, but how would the methods in the nested
Commands object (easily) access the data members of MyObject? I realy don't
want to have to create an instance of Commands and pass it a bunch of data
to initialize it. All I want to do is group methods/properties of MyObject
so the user of the class doesn't have to deal with tons of methods off the
root of the object.

Am I thinking along the wrong lines? Is there another/better/more proper
way to do this? Or am I crazy for even wanting to do such a strange thing?
:)
 
In VB.NET:

Public Class MyClass

Private m_InnerClass As New MyInnerClass

Public Readonly Property InnerClass() As MyInnerClass
Get
Return m_InnerClass
End Get
End Property

End Class

When you create an instance of MyClass, e.g.

Dim mc as New MyClass

you can get at the inner class by

mc.InnerClass.SomeMethod

HTH

Charles
 
Right, but how would the methods and properties of m_InnerClass access the
data in MyClass? The methods and proprties I want to put in MyInnerClass
are all methods and properties that need to work with the data in MyClass.
I realy don't want to have MyClass pass it's data into m_InnerClass when it
instantiates it. That just sounds so kludgy, not to mention having two
copies of the data for what is really (to the user to MyClass) just one
object. I don't want the methods and properties to be "separate" from
MyClass, just "grouped" somehow so there aren't so many of them off the root
of the MyClass object. But I don't think there is a way I can do that
without separating the methods and properties from MyClass. :(
 
nobody said:
Right, but how would the methods and properties of m_InnerClass
access the data in MyClass? The methods and proprties I want to put
in MyInnerClass are all methods and properties that need to work with
the data in MyClass. I realy don't want to have MyClass pass it's
data into m_InnerClass when it instantiates it. That just sounds so
kludgy, not to mention having two copies of the data for what is
really (to the user to MyClass) just one object. I don't want the
methods and properties to be "separate" from MyClass, just "grouped"
somehow so there aren't so many of them off the root of the MyClass
object. But I don't think there is a way I can do that without
separating the methods and properties from MyClass. :(
Click to expand...

To access an object you need to pass a reference. In this case, pass a
reference to a MyClass object to the InnerClass object.

Object references have nothing to do with the project structure (assemblies,
(nested) namespaces/classes), so the InnerClass object does not "know" that
there is an outer class (MyClass) at design time. There might be none or
multiple instances of MyClass at run time.


--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html
 
The usual way would be to pass a reference when m_InnerClass is
instantiated.

Public Class MyClass

Private m_InnerClass As New MyInnerClass(Me)

Public Readonly Property InnerClass() As MyInnerClass
Get
Return m_InnerClass
End Get
End Property

End Class

Public Class MyInnerClass

Private m_Parent As MyClass

Public Sub New(Parent As MyClass)

m_Parent = Parent

End Sub

Public Sub DoStuffInvolvingMyClass()

m_Parent.SomeMethod()

...

End Sub

End Class

This doesn't create two copies of your data as you are only passing a
reference. The user of your class will see the effect you want without
knowing anything about how it is implemented internally.

HTH

Charles
 
Now that's one I didn't think of... It would require that all of MyClass's
data that needs to be accessible to MyInnerClass would have to be exposed
publicly (or friendly)... Maybe I could have a class to hold all of
MyClass's private data, and pass a reference to that into MyInnerClass....
I'll play that idea around in my mind for awhile (it might get lonely in
there though...) :)

Thanks all!
 
Back
Top