Da Ihr Problem hauptsächlich stilistischer Natur ist (nicht den Konstruktor mit einer Vielzahl von Deklarationen füllen möchten), kann es auch stilistisch gelöst werden.
Meiner Ansicht nach haben viele Klassen basierte Sprachen den Konstruktor als eine Funktion mit dem Namen der Klassen selbst. Stilistisch könnten wir das verwenden, um eine ES6-Klasse zu erstellen, die stilistisch immer noch Sinn macht, aber die typischen Aktionen, die im Konstruktor stattfinden, nicht mit all den Eigenschaftsdeklarationen gruppieren, die wir machen. Wir verwenden einfach den tatsächlichen JS-Konstruktor als "Deklarationsbereich" und erstellen dann eine Klassen benannte Funktion, die wir sonst als "anderer Konstruktorbereich" behandeln, und rufen sie am Ende des wirklichen Konstruktors auf.
"use strict";
class MyClass
{
// Deklarieren Sie nur Ihre Eigenschaften und rufen Sie this.ClassName(); von hier aus auf
constructor(){
this.prop1 = 'blah 1';
this.prop2 = 'blah 2';
this.prop3 = 'blah 3';
this.MyClass();
}
// Alle möglichen anderen "Konstruktor" Aufgaben, nicht mehr mit Deklarationen vermischt
MyClass() {
doWhatever();
}
}
Beide werden aufgerufen, wenn die neue Instanz erstellt wird.
So ähnlich wie zwei Konstruktoren zu haben, in denen Sie die Deklarationen und die anderen Konstruktoraktionen, die Sie ausführen möchten, trennen, und stilistisch macht es auch nicht zu schwer zu verstehen, was dabei vor sich geht.
Ich finde es einen schönen Stil, wenn man es mit vielen Deklarationen und/oder vielen Aktionen zu tun hat, die beim Instanziieren ausgeführt werden müssen, und die beiden Ideen voneinander getrennt halten möchte.
HINWEIS: Ich verwende absichtlich nicht die typischen idiomatischen Ideen von "Initialisierung" (wie eine init() oder initialize() Methode), weil diese oft unterschiedlich verwendet werden. Es gibt eine Art unterstellter Unterschied zwischen der Idee des Konstruierens und der Initialisierung. Wenn man mit Konstruktoren arbeitet, weiß man, dass sie automatisch als Teil der Instanziierung aufgerufen werden. Wenn man eine init Methode sieht, werden viele Menschen ohne genaues Hinsehen davon ausgehen, dass sie etwas in der Form von var mc = MyClass(); mc.init(); tun müssen, weil Sie normalerweise initialisieren. Ich versuche keinen Initialisierungsprozess für den Benutzer der Klasse hinzuzufügen, sondern ich versuche, ihn an den Konstruktionsprozess der Klasse selbst anzufügen.
Obwohl manche Leute vielleicht einen Moment lang zweifeln, das ist eigentlich der eigentliche Punkt: Es kommuniziert ihnen, dass die Absicht Teil der Konstruktion ist, auch wenn sie einen kurzen Moment innehalten und sagen "so funktionieren ES6 Konstruktoren nicht" und dann einen zweiten Blick auf den tatsächlichen Konstruktor werfen und sagen "oh, sie rufen ihn unten auf, ich verstehe", das ist viel besser als die Absicht nicht zu kommunizieren (oder sie falsch zu kommunizieren) und wahrscheinlich viele Menschen dazu zu bringen, sie falsch zu verwenden, sie von außen zu initialisieren und so weiter. Das ist sehr beabsichtigt für das Muster, das ich vorschlage.
Für diejenigen, die diesem Muster nicht folgen möchten, kann auch das genaue Gegenteil funktionieren. Lassen Sie die Deklarationen am Anfang in eine andere Funktion auslagern. Vielleicht nennen Sie es "Eigenschaften" oder "publicProperties" oder so etwas. Dann setzen Sie den Rest der Dinge in den normalen Konstruktor.
"use strict";
class MyClass
{
properties() {
this.prop1 = 'blah 1';
this.prop2 = 'blah 2';
this.prop3 = 'blah 3';
}
constructor() {
this.properties();
doWhatever();
}
}
Beachten Sie, dass diese zweite Methode zwar sauberer aussehen kann, aber auch ein inhärentes Problem hat, bei dem properties überschrieben wird, wenn eine Klasse, die diese Methode verwendet, eine andere erweitert. Sie müssten properties eindeutigere Namen geben, um das zu vermeiden. Meine erste Methode hat dieses Problem nicht, weil ihr falscher Teil des Konstruktors nach der Klasse eindeutig benannt ist.
