Nested Classes and Thrown Beer

[JaJangMyeon]

I'm sitting in the local pub, one of my co-workers just stormed out after throwing her beer on my other co-worker. Monday morning is going to suck. The definition of a nerd is someone who throws their beer on someone over a disagreement on something like nested classes. I'm not kidding.

So I thought that since it isn't too far off my last question, I posted it here and see what everyone else's opinion is.

The question was whether or not to use nested classes. The one wearing the beer said that nested classes make it easy to break up complicated classes into "chunks" that pertain only to the class above it. Like have a class called alphabet, with nested classes for each letter.

The beer thrower claimed that it was bad form and that it was lazy, that you could always find a way to break out the nested classes into individual classes, providing for a flatter design, reducing code depth and some other things I didn't really understand.

The one wearing the beer asked her if she ever used nested structures, to which she responded of course. He then asked her what the difference was and that he could rewrite the nested classes as nested structures. He wanted to know why being called a class versus a struct made any difference.

Now I don't know anything about that last part; but I have a few questions:

1) Is it possible to completely rewrite a class substructure as a struct?
2) Is nesting classes that have a singular focus the methods of the class above them ok, in order to reduce the size of any one class and create a more logical structure?
3) What other benefits are there to nesting or drawbacks?
4) Is the concept of nesting classes one of those things that object oriented programmers necessarily get heated up over? Is using it that egregious and why?

By the way, he called her "inconsistent" and she flew off the handle, hence the reason why he smells like pumpkin spice beer (which I consider a much more egregious offense).

Looking forward to thoughts

[jonnin]

thoughts? Don't socialize with co-workers involving alcohol. Nothing good ever comes of this.

[dhayden]

1) Is it possible to completely rewrite a class substructure as a struct?

As I recall, in C++ this:

struct MyStruct {
   stuff
};

is exactly equivalent to:

class MyStruct {
public:
   stuff
};

In other words, the only difference is that with class, members are protected by default, and with struct, they are public. You could literally turn a struct into a class with cut & paste.

2) Is nesting classes that have a singular focus the methods of the class above them ok

One purpose of a class is to enforce logical consistency of the data. If the some subset of the data remains logically consistent within itself then sure, knock yourself out and create a subclass.

It's a matter of personal taste otherwise I suppose. For me, I haven't don't nested classes because they make it harder to remember which a particular member is located. "I need to call that brimblebat() method. Let's see... is that obj.nest1.brimblebat() or obj.nest2.brimblebat()?" In this scenario, nesting has made the class harder to use.

But mostly it doesn't matter and worrying about such things can distract you from the real issue: writing correct code. The more people worry about formatting conventions and where to use upper vs. lower case in the code and dogmatically following some programming rule, the less time they have to worry about the actual code, and that means they're likely to screw it up, regardless of what coding-fashion magazine they read and which coding season it is.

[Repeater]

This sounds like it's related to private implementations; the technique by which a class is given a (pointer to) another class that nobody else can see. That is typically done for reasons other than wanting to make classes invisible from outside, but in my experience I seem to spend a lot more time destroying these private implementations where I find them than creating new ones.

[Repeater]

Oh, and as for pub conversation. I always find "What would win in a fight; a tiger or a shark?" does a lot better than one would expect.

[doug4]

I would nest classes if the inner class were inherently part of the outer class. One classic example is a Node class. A Linked List class might have a Node class that has a "next" pointer. A Doubly Linked List class might have a Node class with "next" and "previous" pointers. A Binary Tree class might have a Node class with "parent", "left child" and "right child pointers.

If you had a program that used all 3 container classes, you could write 3 Node classes in a flat configuration. However, since each Node class is specific to a container class, it makes more sense to nest the Node classes within the container classes.

If the proposed nested class has any significance outside of the containing class, it should probably be a non-nested class.