Tipos aninhados ou outra solução para classes mapeadas um para um

Question

Eu tenho uma classe que precisa de alguma funcionalidade para ser encapsulada de alguma forma.

Eu estava pensando em uma classe aninhada e coloquei essa funcionalidade e alguns estados nela.A relação entre essas duas classes é de um para um.

O problema é acessar as variáveis ​​​​ou métodos dos membros da classe externa, eles devem ser declarados static e eu não quero isso.Outra solução é passar uma referência da classe externa para a classe interna.

Qual é a melhor prática para o meu 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.
    }
}

Então funciona assim:

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

Mas não tenho certeza se é uma boa ideia ou não?!

Answer 2

Embora eu não vá tão longe a ponto de dizer que classes aninhadas são más, elas certamente podem ser "travessas" e há muito poucos problemas que uma classe aninhada resolverá que não poderiam ser resolvidos de maneira diferente ou mais elegante.

Portanto, realmente depende da sua situação específica, mas algumas coisas a considerar são:

1. A classe aninhada ficará publicamente visível?Eles são difíceis de manejar devido à sintaxe que os consumidores devem usar para se referir ao tipo aninhado:TipoExterno + TipoInner

2. Os arquivos de origem ficam maiores em média e são mais difíceis de ler e raciocinar (embora isso possa ser mitigado pelo uso estratégico de classes parciais).

3. A análise de código no Visual Studio reclamará em voz alta sobre classes aninhadas públicas (elas não são consideradas de boa forma pelas diretrizes de design da estrutura), portanto, se você estiver usando o FxCop, precisará fazer exceções.

Se você postar mais detalhes, poderemos fornecer orientações mais detalhadas.

Answer 3

Tivemos exatamente o mesmo problema há cerca de 6 meses, mas por um motivo diferente.Tínhamos cerca de 20 turmas “regulares” e uma turma gigante do tamanho de Júpiter que estava fazendo muito, muito, muito e precisava ser dividida.

Na verdade, precisamos de DOIS filhos, além do pai, com ambos os filhos em um relacionamento de 1 para 1 com o pai.

A primeira tentativa (que funcionou) usou o padrão antigo de passar uma referência de 'this' no construtor de cada filho e, em seguida, usar um método .Parent para navegar de volta.Isso foi um pesadelo devido a problemas de GC e procuramos uma solução melhor em pouco tempo.

A melhor solução (que ainda é usada hoje) era simplesmente aceitar uma referência do tipo de classe do pai nos métodos dos filhos que precisavam consultar o pai.Isso funcionou fantasticamente bem, o GC gostou e tudo foi instanciado e liberado conforme o esperado.O código é mais gerenciável e muito mais organizado, e agora estamos muito felizes por termos investido a tempo para fazê-lo.

Então, essa seria minha recomendação:

Parent
 |
 +-Child1
 |
 +-Child2

Com métodos dos objetos Child aceitando uma referência à classe pai apenas em métodos que precisam dela.

Na verdade, é muito parecido com o modo como o ADO.Net é desenvolvido, com objetos independentes que aceitam referências entre si em métodos onde são necessários.