types emboîtés ou autre solution pour une à une des classes cartographiées

Question

J'ai une classe qui a besoin d'une fonctionnalité à encapsuler d'une certaine façon.

Je pensais à une classe imbriquée, et mettre cette fonctionnalité et quelques états en elle. La relation entre ces deux classes est un à un.

Le problème pour accéder aux variables membres de la classe externe ou les méthodes qu'ils doivent être déclarés static et je ne veux pas. Une autre solution passe d'une référence de la classe externe de classe interne.

Quelle est la meilleure pratique pour mon problème?

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

Ensuite, il fonctionne comme ceci:

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

Mais je ne suis pas sûr que ce soit une bonne idée ou non?!

Answer 2

Alors que je ne voudrais pas aller aussi loin que de dire que les classes imbriquées sont mauvaises, ils peuvent certainement être « espiègle », et il y a très peu de problèmes qu'une classe imbriquée résoudra qui ne peuvent être résolus différemment ou plus d'élégance .

Donc, cela dépend vraiment de votre situation particulière, mais certaines choses à prendre en compte sont:

1. est la classe imbriquée va être publiquement visible? Ceux-ci sont difficiles à manier en raison des consommateurs de syntaxe doivent utiliser pour désigner le type imbriqué: OuterType + InnerType

2. Les fichiers sources grossissent en moyenne, et sont plus difficiles à lire et à raisonner sur (bien que cela puisse être atténué par l'utilisation stratégique des classes partielles).

3. Analyse du code dans Visual Studio se plaindra bruyamment sur les classes imbriquées publiques (ils ne sont pas considérés comme une bonne forme par les lignes directrices de conception-cadre gens), donc si vous utilisez FxCop, vous aurez besoin de faire des exceptions.

Si vous publiez des plus de détails, nous pourrions être en mesure de fournir des indications plus détaillées.

Answer 3

Nous avons eu exactement la même question il y a environ 6 mois, mais pour une autre raison. Nous avons eu environ 20 classes « régulières » et une classe géante Jupiter taille qui faisait route, chemin, beaucoup trop et devaient être ventilés.

Nous avons besoin en fait deux enfants, en plus des parents, avec les enfants dans un 1 à 1 relation avec le parent.

La première tentative (qui a fait le travail) a utilisé le modèle de la vieille école de passer une référence de « ceci » dans le constructeur de chaque enfant, puis en utilisant une méthode .Parent pour naviguer vers le haut. Ce fut un cauchemar en raison de problèmes de GC, et nous avons cherché une meilleure solution en peu de temps.

La meilleure solution (qui est encore utilisé aujourd'hui) était d'accepter simplement une référence du type de classe des parents dans les méthodes des enfants qui devaient interroger les parents. Cela a fantastiquement bien, le GC a aimé, et tout instancié et libéré droit comme prévu. Le code est plus facile à gérer, et beaucoup plus organisé, et nous sommes vraiment heureux que nous avons fait l'investissement dans le temps de le faire.

Alors, ce serait ma recommandation:

Parent
 |
 +-Child1
 |
 +-Child2

Avec les méthodes des objets enfants acceptant une référence à la classe parente que dans les méthodes qui en ont besoin.

Il est en fait un peu comme la façon dont ADO.Net se développe, avec des objets indépendants qui acceptent des références à l'autre dans les méthodes où ils sont nécessaires.