Une classe c # devrait-elle générer des instances d'elle-même?

StackOverflow https://stackoverflow.com/questions/256306

  •  05-07-2019
  •  | 
  •  

Question

J'ai une classe qui définit un type CallRate. J'ai besoin d'ajouter la possibilité de créer plusieurs instances de ma classe en lisant les données d'un fichier.

J'ai ajouté une méthode statique à ma classe CallRate qui renvoie un List<CallRate>. Est-il possible qu'une classe génère de nouvelles instances d'elle-même en appelant l'un de ses propres constructeurs? Cela fonctionne, je me demande si c'est la bonne chose à faire. 

List<CallRates> cr = CallRates.ProcessCallsFile(file);
Était-ce utile?

La solution

Il est parfaitement correct d’obtenir un ou plusieurs objets de la méthode statique.

par exemple

Une des bibliothèques de réseau de points fait la même chose que vous, 

XmlReadrer reader = XmlReader.Create(filepathString);

Autres conseils

Bien sûr, ça va, même encouragé dans certains cas. Il existe plusieurs modèles de conception traitant de la création d'objets , et quelques-uns le font ce que vous décrivez.

J'utilise souvent ce modèle lorsque j'ai besoin de vérifier la validité des paramètres. Il est fortement déconseillé de lancer une exception d'un constructeur. Ce n’est pas si grave avec une méthode fabrique, ou vous pouvez choisir de renvoyer null.

Cela me semble bien. Dans d’autres langages, vous écririez probablement une fonction, mais dans un langage comme C #, les méthodes statiques assument ce rôle.

C'est bon. Ce que vous venez de créer s'apparente à une méthode d'usine simple. Vous avez une méthode statique qui crée une instance valide d'un type. En fait, votre méthode n'a même pas besoin d'être statique et vous avez toujours un code valide. Il existe un modèle de conception (prototype) qui crée un nouvel objet valide à partir d'un objet existant. Voir les détails à l'adresse http://www.dofactory.com/Patterns/PatternPrototype.aspx . .

Bien sûr, pour des scénarios d'analyse simples (ou similaires), je préfère plutôt le méthode d'usine faire partie de la classe. Oui, il casse SRP , mais il remplit KISS - je l'appelle donc un gain net. Pour les applications plus volumineuses ou les routines d’analyse plus complexes, il est plus logique d’en faire une classe de fabrique externe.

Pour votre cas particulier, je préférerais probablement une méthode qui prenait IEnumerable < string > au lieu d'un nom de fichier - cela vous donnerait quand même la logique d'analyse, mais vous permettriez des tests unitaires faciles et & "; réutilisez &"; L'appelant peut encapsuler le fichier dans un IEnumerable assez facilement.

Les méthodes d’usine sont souvent une bonne conception. Quand je les écris en C #, je les appelle "Nouveau", de sorte que: 

new MyClass()

devient 

MyClass.New()

Trivialement, il est implémenté comme ceci: 

class MyClass
{
    public static MyClass New()
    {
        return new MyClass();
    }
}

Généralement, je le fais lorsque des conditions supplémentaires s'appliquent: créer la classe ou simplement renvoyer null, ou renvoyer MyClass ou quelque chose qui en dérive.

J'utilise parfois des méthodes statiques publiques comme alternative à la surcharge du constructeur.

Surtout dans les situations où il n’est pas intéressant de s’appuyer uniquement sur des types de paramètres pour indiquer le type de construction d’objet souhaité.

Je suis fan des méthodes statiques qui renvoient des instances, comme suggéré plus haut.

@Paul: n'oubliez pas de cocher le commentaire ci-dessus, qui est la meilleure réponse.

Je voudrais juste souligner " générer de nouvelles instances de lui-même en appelant l'un de ses propres constructeurs "

Ce n'est pas du constructeur, mais de la méthode statique.

J'utilise généralement cela lorsque j'ai besoin d'implémentations instantanées d'une classe. Par exemple 

    public class Car
    {
        public static Car RedExpensiveCar = new Car("Red", 250000);

        public Car()
        {

        }

        public Car(string color, int price)
        {
            Color = color;
            Price = price;
        }

        public string Color { get; set; }
        public int Price { get; set; }
    }

Et avec cela, je n'ai pas besoin de me souvenir ni d'écrire des paramètres de constructeur dans mon code. 

Car car = Car.RedExpensiveCar;

C'est parfaitement acceptable. Lorsque je le fais, je rends généralement les constructeurs de la classe privés afin qu'il soit clair que la manière seulement de construire des instances s'effectue via la méthode statique.

Ceci est très utile dans les cas où " construction " peut ne pas toujours renvoyer une nouvelle instance. Par exemple, vous souhaiterez peut-être renvoyer un objet précédemment mis en cache.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top