views:

161

answers:

4

Hello everybody

I am thinking that if a class will be instantiated only in another class so it is right to use it nested in that class.I think this will help us good design.When i look at my project i have almost never seen such nested structure.But if i try to nested classes so this time another questions appear in my mind.For example

I have Board class, Move classes such as ShortCastle,LongCastle,EnPassant,Promote and Pieces like Pawn,Queen,Rook,Knight etc. So it is clear Board classes will instantiate Piece classes and Piece classes will instantiate Move classes. For a good design,Promote move class should to be nested of Pawn because only pawn can promote itself.short and long Castles should to be nested of King because only king can have such type moves.

Trying to put all Piece classes into Board class is not looking good design because 8-9 class will be inside of Board class and it will really annoying one Board class file will be too large and hardly readable.I prefer keep each piece class in another file. Good that we can create partial Board class but still isn't it annoying 8-9 Partial Board class files will hold each piece class? Is it better to not make them nested ? Same about Pieces Create another partial Piece file just for another Move type class ? If nested class just take small space so it wouldn't be any problem but if it takes many methods ?

+8  A: 

I think you are too generous with nested classes. Have a look at this design guideline for nested types.

Do not use nested types if the following are true:

  • The type must be instantiated by client code. If a type has a public constructor, it probably should not be nested. The rationale behind this guideline is that if a nested type can be instantiated, it indicates that the type has a place in the library on its own. You can create it, use it, and destroy it without using the outer type. Therefore, it should not be nested. An inner type should not be widely reused outside of the outer type without a relationship to the outer type.
  • References to the type are commonly declared in client code.

The pieces may belong to a board(Piece-collection as a member?) but could coexist without of it.

Tim Schmelter
+2  A: 

Private members from parent class are accessible to Nexted Class methods.

Nexted class allows reduce complexity without broad Scope.

x77
A: 

If you truly, truly think nested classes make sense for your design (see Tim Schmelter's admonitions) but feel the file size is too big, the use of partial classes is fine to split the nested class defintions into their own files. Or if the nested classes are small enough on their own but you have a large number of them, put all the nested classes into one partial file.

Parent.cs:

public partial class Parent
{
    void SomeMethod()
    {
        Nested1 n1 = new Nested1();
        Nested2 n2 = new Nested2();
    }
}

Nested.cs:

public partial class Parent
{
    private class Nested1
    {

    }
    private class Nested2
    {

    }
}
Tim Trout
+1  A: 

For a good design,Promote move class should to be nested of Pawn because only pawn can promote itself.

I don't really agree. Just because you can nest classes doesn't mean you should. Ask yourself what benefit you're getting from nesting these classes.

Jon Nadal
You restrict posibilities of mistakes with this design.None of other Pieces can not create such a move, even wrongly.This design doesn't let it.Am i wrong ?
Freshblood
Deeply nesting classes limits their scope (which could be a helpful architectural constraint in certain scenarios), but you're taking on a lot of complexity early in your project. I'd recommend doing "the simplest thing that could work" and then refactoring to a more complex design when the need arises.Later, if you'd like to constrain where certain classes can be instantiated from, you could break up your solution into different assemblies (by creating "Class Library" projects).Good luck! =)
Jon Nadal