tipos anidados u otra solución de uno a uno las clases asignadas

Question

Tengo una clase que necesita alguna funcionalidad a ser encapsulada de alguna manera.

Yo estaba pensando en una clase anidada, y poner esa funcionalidad además de algunos estados en él. La relación entre estas dos clases es uno-a-uno.

El problema para acceder a las variables miembro de la clase externa o métodos que deben ser objeto de declaración static y yo no lo quiero. Otra solución está pasando una referencia de la clase externa a clase interna.

¿Cuál es la mejor práctica para mi problema?

Answer 1

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.
    }
}

A continuación, funciona así:

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

Pero no estoy seguro de si esto es una idea buena o no?!

Answer 2

Mientras yo no iría tan lejos como para decir que las clases anidadas son malos, que sin duda puede ser "traviesa", y hay muy pocos problemas que una clase anidada resolverá que no podían ser resueltos de manera diferente o más elegante .

Así que realmente depende de su situación específica, pero algunas cosas a tener en cuenta son:

1. ¿Es la clase anidada va a ser visible para el público? Estos son difíciles de manejar debido a los consumidores sintaxis debe utilizar para referirse al tipo anidado: OuterType + InnerType

2. Los archivos de origen se hacen más grandes en promedio, y son más difíciles de leer y razonar sobre (aunque esto puede ser mitigado mediante el uso estratégico de las clases parciales).

3. Análisis de código en Visual Studio se quejan en voz alta sobre las clases anidadas públicas (que no están considerados forma buena de las directrices de diseño marco de la gente), por lo que si usted está utilizando FxCop que necesita para hacer excepciones.

Si publica algunos datos más específicos, que podría ser capaz de proporcionar una orientación más detallada.

Answer 3

Hemos tenido exactamente el mismo problema hace aproximadamente 6 meses, pero por una razón diferente. Tuvimos cerca de 20 clases de 'regular' y uno gigante Júpiter tamaño de clase que estaba haciendo mucho, mucho, demasiado y necesitaba ser desglosado.

En realidad necesitamos dos hijos, además de los padres, con los dos niños en una relación 1-a-1 a los padres.

El primer intento (que hizo el trabajo) utiliza el patrón de la vieja escuela de pasar una referencia de 'esto' en el constructor de cada niño, y luego usando un método .parent a volver a navegar. Eso fue una pesadilla debido a problemas de GC, y buscamos una solución mejor en poco tiempo.

La mejor solución (que todavía se utiliza hoy en día) era aceptar simplemente una referencia de tipo de clase de los padres en los métodos de los niños que necesitaban para consultar a los padres. Esto funcionó fantásticamente bien, la GC le gustó, y todo lo que crea una instancia y liberó a la derecha como se esperaba. El código es más manejable, y mucho más organizada, y ahora estamos muy contentos de haber hecho la inversión de tiempo para hacerlo.

Por lo tanto, eso sería mi recomendación:

Parent
 |
 +-Child1
 |
 +-Child2

Con los métodos de los objetos secundarios de aceptar una referencia a la clase padre sólo en los métodos que lo necesitan.

En realidad es muy parecido a la forma en que se desarrolla ADO.Net, con objetos independientes que aceptan referencias entre sí en los métodos en los que se necesitan.