Nested types or other solution for one to one mapped classes

I have a class which needs some functionality to be encapsulated in some way.

I was thinking of a nested class, and put that functionality plus some states into it. The relation between these two classes 开发者_运维知识库is one-to-one.

The problem it for accessing the outer class member variables or methods they should be declared static and I don't want it. Another solution is passing a reference of the outer class to inner class.

What's the best practice for my problem ?

While I wouldn't go as far as to say that nested classes are evil, they certainly can be "mischievous", and there are very few problems that a nested class will solve that couldn't be solved differently or more elegantly.

So it really depends on your specific situation, but some things to consider are:

1. Is the nested class going to be publicly visible? These are unwieldy due to the syntax consumers must use to refer to the nested type: OuterType+InnerType

2. Source files get larger on average, and are harder to read and reason about (although this may be mitigated by the strategic use of partial classes).

3. Code Analysis in Visual Studio will complain loudly about public nested classes (they're not considered good form by the framework design guidelines folks), so if you're using FxCop you'll need to make exceptions.

If you post some more specifics, we might be able to provide more detailed guidance.

We had exactly the same issue about 6 months ago, but for a different reason. We had about 20 'regular' classes and one giant Jupiter sized class that was doing way, way, way too much and needed to be broken down.

We actually need TWO children, in addition to the parent, with both children in a 1-to-1 relationship to the parent.

The first attempt (which did work) used the old-school pattern of passing a reference of 'this' in the constructor of each child, and then using a .Parent method to navigate back up. That was a nightmare due to GC issues, and we looked for a better solution in short time.

The best solution (which is still used today) was to simply accept a reference of the parent's class type in methods of the children which needed to query the parent. This worked fantastically well, the GC liked it, and everything instantiated and freed right as expected. The code is more manageable, and a lot more organized, and we're now really glad we made the investment in time to do it.

So, that would be my recommendation:

Parent
 |
 +-Child1
 |
 +-Child2

With methods of the Child objects accepting a reference to the parent class only in methods that need it.

It's actually a lot like the way that ADO.Net is developed, with independent objects that accept references to each other in methods where they are needed.

using System;

class OuterType
{
    private static OuterType _instance;

    public OuterType()
    {
        _instance = this;
    }

    private String Message
    {
        get { return "Hello from OuterType"; }
    }

    public void testInnerType()
    {
        InnerType innerType = new InnerType();
        Console.WriteLine(innerType.FormattedOutertMessage);
    }

    private class InnerType
    {
        private readonly OuterType _outerType = _instance;

        public String FormattedOutertMessage
        {
            get { return _outerType.Message.ToUpper(); }
        }
        // InnerType doesn't need to dispose any object of OuterType.
    }
}

Then it works like this:

class Program
{
    static void Main(string[] args)
    {
        OuterType outerType = new OuterType();
        outerType.testInnerType();
        Console.ReadKey();
    }
}

But I'm not sure if this is a good idea or not ?!