Je me considère toujours comme un apprenti programmeur, donc je cherche toujours à apprendre une "meilleure" façon de programmer en général. Aujourd'hui, mon collègue a soutenu que mon style de codage fait un travail inutile et je veux entendre les opinions des autres. En règle générale, lorsque je conçois une classe en langage OOP (généralement C ++ ou Python), je sépare l'initialisation en deux parties différentes:
class MyClass1 {
public:
Myclass1(type1 arg1, type2 arg2, type3 arg3);
initMyClass1();
private:
type1 param1;
type2 param2;
type3 param3;
type4 anotherParam1;
};
// Only the direct assignments from the input arguments are done in the constructor
MyClass1::myClass1(type1 arg1, type2 arg2, type3 arg3)
: param1(arg1)
, param2(arg2)
, param3(arg3)
{}
// Any other procedure is done in a separate initialization function
MyClass1::initMyClass1() {
// Validate input arguments before calculations
if (checkInputs()) {
// Do some calculations here to figure out the value of anotherParam1
anotherParam1 = someCalculation();
} else {
printf("Something went wrong!\n");
ASSERT(FALSE)
}
}(ou équivalent python)
class MyClass1:
def __init__(self, arg1, arg2, arg3):
self.arg1 = arg1
self.arg2 = arg2
self.arg3 = arg3
#optional
self.anotherParam1 = None
def initMyClass1():
if checkInputs():
anotherParam1 = someCalculation()
else:
raise "Something went wrong!"Quelle est votre opinion sur cette approche? Dois-je m'abstenir de fractionner le processus d'initialisation? La question n'est pas seulement limitée à C ++ et Python, et les réponses pour d'autres langages sont également appréciées.
design
object-oriented
coding-style
Caladbolgll
la source
la source
Réponses:
Bien que cela soit parfois problématique, l'initialisation de tout dans le constructeur présente de nombreux avantages:
initMyClass1()car il n'est pas là . "Les composants les moins chers, les plus rapides et les plus fiables sont ceux qui ne sont pas là."la source
Pensez à l'abstraction que vous fournissez à vos utilisateurs.
Pourquoi scinder quelque chose qui pourrait être fait en un seul coup en deux?
L'initialisation supplémentaire est juste quelque chose de supplémentaire pour les programmeurs qui utilisent votre API pour se souvenir, et fournit plus pour se tromper s'ils ne le font pas correctement, mais pour quelle valeur pour eux pour ce fardeau supplémentaire?
Vous voulez fournir des abstractions simples, faciles à utiliser et difficiles à utiliser. La programmation est assez difficile sans choses gratuites à retenir / cerceaux à franchir. Vous voulez que vos utilisateurs d'API (même si ce n'est que vous qui utilisez votre propre API) tombent dans le gouffre du succès .
la source
Initialisez tout sauf la zone Big Data. Les outils d'analyse statique signaleront les champs non initialisés dans le constructeur. Cependant, le moyen le plus productif / sûr est d'avoir toutes les variables membres avec des constructeurs par défaut et d'initialiser explicitement uniquement celles qui nécessitent une initialisation non par défaut.
la source
Il y a des cas où l'objet a beaucoup d'initialisation qui peut être divisé en deux catégories:
Les attributs qui sont immuables ou n'ont pas besoin d'être réinitialisés.
Attributs qui pourraient avoir besoin de revenir aux valeurs d'origine (ou valeurs modélisées) en fonction d'une condition après avoir accompli leur travail, une sorte de réinitialisation logicielle. par exemple des connexions dans un pool de connexions.
Ici, la deuxième partie de l'initialisation étant conservée dans une fonction séparée, par exemple InitialiseObject (), peut être appelée dans le ctor.
La même fonction peut être appelée ultérieurement si une réinitialisation logicielle est requise, sans avoir à supprimer et recréer l'objet.
la source
Comme d'autres l'ont dit, c'est généralement une bonne idée d'initialiser dans le constructeur.
Il existe cependant des raisons pour lesquelles cela peut ne pas s'appliquer dans certains cas.
La gestion des erreurs
Dans de nombreux langages, la seule façon de signaler une erreur dans un constructeur est de lever une exception.
Si votre initialisation a une chance raisonnable de déclencher une erreur, par exemple si elle implique des entrées-sorties ou si ses paramètres peuvent être saisis par l'utilisateur, alors le seul mécanisme qui vous est ouvert est de lever une exception. Dans certains cas, cela peut ne pas être ce que vous voulez et il peut être plus judicieux de séparer le code sujet aux erreurs en une fonction d'initialisation distincte.
L'exemple le plus courant est probablement en C ++ si la norme de projet / organisation est de désactiver les exceptions.
Machine d'état
C'est le cas lorsque vous modélisez un objet qui a des transitions d'état explicites. Par exemple, un fichier ou un socket qui peut être ouvert et fermé.
Dans ce cas, il est courant que la construction (et la suppression) d'objet ne traite que des attributs orientés mémoire (nom de fichier, port, etc.). Il y aura ensuite des fonctions pour gérer spécifiquement les transitions d'état, par exemple ouvrir, fermer, qui sont effectivement des fonctions d'initialisation et de suppression.
Les avantages résident dans la gestion des erreurs, comme ci-dessus, mais il peut également être judicieux de séparer la construction de l'initialisation (par exemple, vous créez un vecteur de fichiers et vous les ouvrez de manière asynchrone).
L'inconvénient, comme d'autres l'ont dit, est que vous imposez désormais la charge de la gestion de l'état à l'utilisateur de vos classes. Si vous pouviez gérer avec juste la construction, vous pourriez, par exemple, utiliser RAII pour le faire automatiquement.
la source