Mauvaise pratique pour inclure le code dans le constructeur par défaut

C'est une question de goût. Je trouve ces règles définies par l'utilisateur Kokos très utile:

SON RÈGLES:

1. Ne pas initialiser avec les valeurs par défaut dans la déclaration (NULL, FAUX, 0, 0,0 ...).
2. Préférez l'initialisation dans la déclaration si vous n'avez pas de paramètre de constructeur qui modifie la valeur du champ.
3. Si la valeur du champ change à cause d'un paramètre de constructeur, mettez l'initialisation dans les constructeurs.
4. soyez cohérent dans votre pratique. (la règle la plus importante)

   Voir: Initialiser les champs de classe dans le constructeur ou à Déclaration?

Depuis que vous utilisez C # avec le framework .NET. Permettez-moi de vous donner l'article complet "Conception du constructeur" de MSDN:

http://msdn.microsoft .Com / fr-US / bibliothèque / vstudio / ms229060 (v = vs.100) .aspx

À mon avis, vous devez mettre juste code d'initialisation dans votre constructeur.

Les champs de classe Uinitialisés devraient généralement se retrouver dans le constructeur par défaut. Si vous initialisez les champs de classe sur la même ligne que les déclarations, ces déclarations ne s'exécuteront pas si vous désérialisez un tel objet. En outre, il est une bonne pratique pour collecter toutes les initalisations dans la CTOR par défaut.

Que vient à l'esprit est l'article 17 de Java efficace (par Joshua Bloch):

Point 17: Conception et document pour l'héritage ou d'autres interdire

Il explique qu'un constructeur ne doit pas appeler des méthodes qui sont excessives: xxx

Ce qui finit par arriver, c'est que vous appelez le constructeur de la superclasse (quand vous invoquez Créez une instance de la sous-classe) et vous obtenez un comportement inattendu.

Si votre constructeur invoque d'autres méthodes de la classe, vous devez le documenter dans votre API afin que les développeurs se subglassent, ils sauront à quoi s'attendre. .

Sinon, il n'y a pas de mal à mettre le code dans votre constructeur.

Lorsque vous désérialisez un objet avec un formidateur binaire, le constructeur par défaut n'est pas exécuté lorsque l'objet est créé. Le BinaryFormatter utilise une astuce pour obtenir .NET pour donner une instance initialisée dans laquelle aucun constructeur par défaut n'est exécuté.

Cela ne devrait pas poser de problème, car le formidateur Binary se remplit dans tous les membres privés eux-mêmes. La seule situation que je puisse imaginer être dangereuse, c'est si vous utilisez le constructeur par défaut pour "enregistrer" l'objet quelque part dans une autre classe statique ou quelque chose selon ces lignes, auquel cas vous avez un nouvel ensemble de problèmes.

règle de pouce

Rendez-le aussi simple que possible.

L'ensemble du point de bonnes normes de codage est pour la maintenabilité et la capacité de débogage. Nous avons tous rencontré du code qui est spaghetti. Ceci est juste pour que d'autres comprennent votre API mieux. Même avec un bon Javadoc, la plupart des gens ne sont pas attendre le constructeur pour changer l'état de l'application.

Par exemple, si l'instanciation de votre objet fait une manipulation de la base de données, vous feriez mieux de vous amuser une bonne raison.

Exemple de comptoir

Vous devez toujours faire ce qui est le meilleur. Si vous décidez d'avoir un singleton chargé de paresseux qui charge un cache ou une connexion ou qu'est-ce que vous avez, le point entier est qu'il chargera automatiquement quelque chose lorsque vous l'instanciez.