由于您的问题主要是风格上的(不想用一堆声明填充构造函数),它也可以在风格上解决。
在我看来,许多基于类的语言的构造函数都是以类名本身命名的函数。从风格上讲,我们可以使用它来制作一个风格上仍然有意义的 ES6 类,但不会将构造函数中发生的典型动作与我们正在做的所有属性声明组合在一起。我们简单地将实际的 JS 构造函数用作“声明区”,然后创建一个名为函数的类,否则我们将其视为“其他构造函数”区域,在真正的构造函数的末尾调用它。
“使用严格”;
我的班级
{
// 只声明你的属性然后调用 this.ClassName(); 从这里
构造函数(){
this.prop1 = '废话 1';
this.prop2 = '废话 2';
this.prop3 = '废话 3';
this.MyClass();
}
// 各种其他“构造函数”的东西,不再与声明混为一谈
我的课() {
随便();
}
}
两者都将在构造新实例时被调用。
有点像拥有 2 个构造函数,您可以在其中将声明和您想要执行的其他构造函数操作分开,并且从风格上来说,这也使您不难理解正在发生的事情。
我发现在处理大量声明和/或需要在实例化时发生的大量动作并希望使这两个想法彼此不同时使用它是一种不错的风格。
注意:我非常有目的地不使用“初始化”的典型惯用想法(如init()
orinitialize()
方法),因为它们的使用方式通常不同。构造和初始化的想法之间存在一种假定的差异。使用构造函数的人都知道,它们是作为实例化的一部分自动调用的。看到一种init
方法,许多人会不假思索地认为他们需要按照 的形式做一些事情var mc = MyClass(); mc.init();
,因为这就是您通常初始化的方式。我不是要为类的用户添加初始化过程,而是要添加到类本身的构造过程中。
虽然有些人可能会做一时的双重考虑,但这实际上是重点:它向他们传达意图是构建的一部分,即使这让他们做了一些双重考虑然后去“那不是ES6 构造函数是如何工作的”,然后再看看实际的构造函数去“哦,他们在底部调用它,我明白了”,这比不传达那个意图(或错误传达它)要好得多,而且可能会得到很多人们使用它错误,试图从外部初始化它和垃圾。这对我建议的模式非常有意。
对于那些不想遵循这种模式的人来说,完全相反的方法也可以。在开始时将声明移植到另一个函数。也许将其命名为“properties”或“publicProperties”之类的。然后把剩下的东西放在普通的构造函数中。
“使用严格”;
我的班级
{
特性() {
this.prop1 = '废话 1';
this.prop2 = '废话 2';
this.prop3 = '废话 3';
}
构造函数(){
this.properties();
随便();
}
}
请注意,第二种方法可能看起来更干净,但它也有一个固有的问题,即properties
当使用此方法的一个类扩展另一个类时会被覆盖。您必须提供更多独特的名称properties
以避免这种情况。我的第一个方法没有这个问题,因为它的构造函数的假一半是唯一以类命名的。