Étant donné que votre problème est principalement stylistique (ne pas vouloir remplir le constructeur avec un tas de déclarations), il peut également être résolu stylistiquement.
De la façon dont je le vois, de nombreux langages basés sur les classes ont le constructeur être une fonction nommée d'après le nom de classe lui-même. Stylistiquement, nous pourrions utiliser cela pour créer une classe ES6 qui, sur le plan stylistique, a toujours du sens mais ne regroupe pas les actions typiques se déroulant dans le constructeur avec toutes les déclarations de propriétés que nous faisons. Nous utilisons simplement le constructeur JS réel comme "zone de déclaration", puis faisons une classe nommée fonction que nous traitons autrement comme la zone "autres éléments constructeurs", en l'appelant à la fin du vrai constructeur.
"utiliser strict";
classe MyClass
{
// déclare uniquement vos propriétés, puis appelez this.ClassName (); d'ici
constructeur(){
this.prop1 = 'blah 1';
this.prop2 = 'blah 2';
this.prop3 = 'blah 3';
this.MyClass ();
}
// toutes sortes d'autres trucs "constructeurs", plus mélangés avec des déclarations
Ma classe() {
fais ce que tu veux();
}
}
Les deux seront appelés lors de la construction de la nouvelle instance.
Sorta comme avoir 2 constructeurs où vous séparez les déclarations et les autres actions de constructeur que vous souhaitez entreprendre, et stylistiquement, il n'est pas trop difficile de comprendre que c'est ce qui se passe aussi.
Je trouve que c'est un style agréable à utiliser pour traiter de nombreuses déclarations et / ou de nombreuses actions devant se produire lors de l'instanciation et souhaitant garder les deux idées distinctes l'une de l'autre.
REMARQUE : Je n'utilise pas à dessein les idées idiomatiques typiques de "l'initialisation" (comme une init()
ou une initialize()
méthode) car elles sont souvent utilisées différemment. Il y a une sorte de différence présumée entre l'idée de construire et d'initialiser. En travaillant avec des constructeurs, les gens savent qu'ils sont appelés automatiquement dans le cadre de l'instanciation. En voyant une init
méthode, beaucoup de gens vont supposer sans un second coup d'œil qu'ils doivent faire quelque chose sous la forme de var mc = MyClass(); mc.init();
, car c'est ainsi que vous initialisez généralement. Je n'essaie pas d'ajouter un processus d'initialisation pour l'utilisateur de la classe, j'essaie d'ajouter au processus de construction de la classe elle-même.
Alors que certaines personnes peuvent faire une double prise pendant un moment, c'est en fait le problème: cela leur communique que l'intention fait partie de la construction, même si cela les oblige à faire une double prise et à aller "ce n'est pas comment les constructeurs ES6 fonctionnent "et prennent une seconde en regardant le constructeur réel pour aller" oh, ils l'appellent en bas, je vois ", c'est bien mieux que de NE PAS communiquer cette intention (ou de la communiquer incorrectement) et d'obtenir probablement beaucoup de les gens l'utilisant mal, essayant de l'initialiser de l'extérieur et de la camelote. C'est très intentionnel au schéma que je suggère.
Pour ceux qui ne veulent pas suivre ce modèle, l'exact opposé peut également fonctionner. Fermez les déclarations vers une autre fonction au début. Peut-être le nommer "propriétés" ou "publicProperties" ou quelque chose. Ensuite, mettez le reste des choses dans le constructeur normal.
"utiliser strict";
classe MyClass
{
Propriétés() {
this.prop1 = 'blah 1';
this.prop2 = 'blah 2';
this.prop3 = 'blah 3';
}
constructeur () {
this.properties ();
fais ce que tu veux();
}
}
Notez que cette deuxième méthode peut sembler plus propre, mais elle a également un problème inhérent où elle properties
est remplacée lorsqu'une classe utilisant cette méthode en étend une autre. Il faudrait donner des noms plus uniques properties
pour éviter cela. Ma première méthode n'a pas ce problème car sa fausse moitié du constructeur porte le nom unique de la classe.
this.member = member
chez votre constructeur avec 20-30 paramètres?