Nested Classes

  • Thread starter Thread starter C# Learner
  • Start date Start date
C

C# Learner

Is it not possible to declare a nested class in a seperate file from
its "parent" class -- i.e. in a similar way to the idea of spreading
namespaces over more than one file?
 
AFAIK, no there isn't. Classes that are all members of the same namespace
are 'equal' to each other so Class1 doesn't depend on Class2. However, you
could pull the nested class out and make it it's own class and reference it
accordingly or use inheritance or an interface to accomplish a similar
effect.
 
C# Learner said:
Is it not possible to declare a nested class in a seperate file from
its "parent" class -- i.e. in a similar way to the idea of spreading
namespaces over more than one file?
Click to expand...

Hi C# Learner,

Not in C# v1.0. However, according to the C# v2.0 specification, it will be
possible in C# v2.0.

Joe
 
William Ryan said:
AFAIK, no there isn't. Classes that are all members of the same namespace
are 'equal' to each other so Class1 doesn't depend on Class2. However, you
could pull the nested class out and make it it's own class and reference it
accordingly or use inheritance or an interface to accomplish a similar
effect.
Click to expand...

The situation I have in mind is something like this:

I have a class (MyClass) which is getting big (in lines of code) and
I'd like to break it down into parts. Immediately I see where I could
make an "object" out of some of its functionality.

Now, this new object only needs to be known by MyClass instances, and
nowhere else. I don't want this new class to be "visible" to anything
but MyClass.

Therefore, I decide to make it a nested class. However, this nested
class is fairly big itself, and having to declare it within its
"parent" class, in the same file, is a bit of a burden.

For one thing, all methods of the nested class start at an extra
indentation level. For another, the whole file (including MyClass and
its nested class) remains long.

I guess I'll just have to make another class in the same namespace as
MyClass... Though, in my mind, this is a bit of a "hack".

Cheers
 
C# Learner,

The v2.0 concept is called 'partial' classes, where classes can be spread
over multiple files.

As for what you're working on now, would "internal" work for you? That way,
only classes within your project can see the classes you're building. If
you're worried about creating a dll, for example, where you don't want your
users (i.e., other programmers; consumers of your project) to be able to
access these classes, the internal modifier would be what you would want to
use.

Chris R.
 
Chris R said:
C# Learner,

The v2.0 concept is called 'partial' classes, where classes can be spread
over multiple files.
Click to expand...

I like the sound of that.
As for what you're working on now, would "internal" work for you? That way,
only classes within your project can see the classes you're building. If
you're worried about creating a dll, for example, where you don't want your
users (i.e., other programmers; consumers of your project) to be able to
access these classes, the internal modifier would be what you would want to
use.
Click to expand...

Not really, in this case. What I'm looking for is a way to hide the
nested class from *everything* except its "outer" class.

Looks like I'll have to wait for partial classes.
Chris R.
Click to expand...

Cheers
 
Hello Learner,

I'm confused by your reticence to use "internal". A class is an
abstraction. An object is an instance of a class, complete with data. One
of the underlying assumptions about OOP is that you should hide the objects,
because that's where the real power lies. Hiding a class is not as
important and leads to some interesting issues (which you've discovered).

Yet you are worried not only about hiding the objects, but also about hiding
the class from other code in the same namespace. This seems
counter-intuitive to me.

From where I sit, this is how it works: The "parent" class creates a private
object of a "child" class type. No other code has access to this particular
object. Sure, other classes can instantiate the child class. (Other
classes can instantiate the parent class too). Unless you are buried under
a serpentine mix of Singleton objects and Factory Methods, you should have
little or no negative consequences to using this idea to reduce the
complexity of your class without sacrificing OOP principles.

puzzled by your puzzlement,
--- Nick
 
Nick Malik said:
I'm confused by your reticence to use "internal". A class is an
abstraction. An object is an instance of a class, complete with data. One
of the underlying assumptions about OOP is that you should hide the objects,
because that's where the real power lies. Hiding a class is not as
important and leads to some interesting issues (which you've discovered).

Yet you are worried not only about hiding the objects, but also about hiding
the class from other code in the same namespace. This seems
counter-intuitive to me.
Click to expand...

It's not in the same namespace - it's in the same assembly.

I completely understand this, myself. Suppose I have a project which is
a general purpose network library (like Indy :) - it might deal with
NNTP, HTTP and some other protocols. It's nice, IMO, to be able to
insulate the implementation-specific classes of NNTP from those of
HTTP. The HTTP classes may have access to *some* classes which only
other classes in the assembly have access to (in other words, internal
ones) but it would be nice to be able to give further separation than
is currently possible between the HTTP and NNTP implementation classes.

(Java has separation by namespace, .NET has separation by assembly.
Both are nice concepts, and it would be good to have *both*, IMO.)
 
Nick Malik said:
Hello Learner,

I'm confused by your reticence to use "internal". A class is an
abstraction. An object is an instance of a class, complete with data. One
of the underlying assumptions about OOP is that you should hide the objects,
because that's where the real power lies. Hiding a class is not as
important and leads to some interesting issues (which you've discovered).

Yet you are worried not only about hiding the objects, but also about hiding
the class from other code in the same namespace. This seems
counter-intuitive to me.

From where I sit, this is how it works: The "parent" class creates a private
object of a "child" class type. No other code has access to this particular
object. Sure, other classes can instantiate the child class. (Other
classes can instantiate the parent class too). Unless you are buried under
a serpentine mix of Singleton objects and Factory Methods, you should have
little or no negative consequences to using this idea to reduce the
complexity of your class without sacrificing OOP principles.
Click to expand...

Hi Nick,

Let me give an example of what I'm thinking of here:

I have a namespace called FooProtocol. In this namespace is a bunch
of classes which enable the use of a communication protocol called
FooProtocol.

In the FooProtocol namespace I have a class called Session, which
takes care of a client session of FooProtocol. Now, Session reads
packets from the server and fires events after parsing these packets.

In the code of my Session class, I see a lot of methods which have
similar names like:

ProcessFirstPacketType
ProcessSecondPacketType
ProcessThirdPacketType

etc.

Seeing this, I think so myself, I really should make a Processor or
maybe PacketParser class, whose only purpose is to parse these
packets.

Now, this new class should not be visible to anything but Session,
since it is simply an implementation detail of Session.

Further, I may with to create a Processor class as an implementation
detail of another class in the FooProtocol namespace. In this case,
I'd have to name one SessionProcessor and the other
OtherClassNameProcessor, which in my mind shows without doubt that
these classes should be private nested classes of their relevant
classes.
puzzled by your puzzlement,
--- Nick
Click to expand...

Hope that makes sense!

Cheers
 
I completely understand this, myself. Suppose I have a project which is
a general purpose network library (like Indy :) - it might deal with
NNTP, HTTP and some other protocols. It's nice, IMO, to be able to
insulate the implementation-specific classes of NNTP from those of
HTTP. The HTTP classes may have access to *some* classes which only
other classes in the assembly have access to (in other words, internal
ones) but it would be nice to be able to give further separation than
is currently possible between the HTTP and NNTP implementation classes.
Click to expand...

Yep, that's basically what I'm thinking here.

<snip>

Cheers
 
Back
Top