ES6：我是否在使用class&；在JavaScript中正确混合？

在过去的几天里，我一直在学习ECMAScript 6类、mixin和其他特性，但我不确定我对用例的理解是否正确。下面是一个包含类、子类和mixin的示例片段

class Person{
    constructor (opts){
        for(let prop of Object.keys(opts)){
            this[prop] = opts[prop];
        }
      Person.count++;
    }

    static count = 0;
}

//Greeting Mixin
const Greetings = Person => class extends Person{
    sayHello(){}
}

//Job Mixin
const Jobs = Person => class extends Person{
    getJobs(){}
    getSalary(){}
    setJobs(){}
    setSalary(){}
}

//Subclass
class WorkingPerson extends Jobs(Greetings(Person)){
    constructor(opts){
        super(opts);
        //this.type = 'nice';
    }

    sayHello(){
        if(this.type == 'nice') 
            console.log(`Hello there! Wonderful day isnt it?`);
        else
            console.log(`Ah! Get out of here!`);
    }

    getJobs(){
        return this.jobs;
    }

    setJobs(...jobs){
        this.jobs.push(jobs);
    }

    getSalary(){
        return this.salary;
    }

    setSalary(salary){
        this.salary = salary;
    }
}

let wp = new WorkingPerson({name:'Ajay',jobs:['Digital Evangelist'],salary:10000});
let wp2 = new WorkingPerson({name:'Ron',jobs:['Entertainer'],salary:20000});
let wp3 = new WorkingPerson({name:'Morris',jobs:['Televangelist'],salary:30000});
console.log(`Number of people = ${Person.count}`);

上面的代码中没有错误，我得到了正确的输出。然而，我的mixin实现在语义上正确吗？对于给定的上下文，有一个

作业

和

问候语

混入有意义吗？我读过一篇博客，其中他们将mixin定义为抽象子类。查看示例，他们向给定的类添加了一些小功能。因为这听起来和装饰师的定义很相似，所以我把两者的区别归结为一个公认的答案。它说：

mixin增加了新的功能。装饰器用于修改现有的 功能

这让我想到，如果

作业

和

问候

是混合的，那么在这种情况下，你会给装饰师举什么样的例子？如果我有任何错误，请提供正确答案的代码块

---

另外，有没有更好的方法来提供输入参数，而不是在实例化

工作人员时抛出一些原始对象作为参数？
嗯..装饰师不是一个建议吗？这可能是错误的，但我认为这可能是未来的状态（哦，我们需要保持的速度…）

我的理解是：在您的上下文中，假设您希望“jobs”是只读的。一个装饰师可以胜任这项工作

比如：

function readonly ( target, key, descriptor ) {
    descriptor.writable = false;
    return descriptor;
}

// import the decorator function
import { readonly } from 'my-decorators';

class Person {
  @readonly
  person ( ) { return this.user; }
}

因此，我们在这里将该属性的行为修改为隐式只读，而不是将其隐藏在闭包之类的东西中。我还猜想，现在这个属性可以作为“只读”属性进行检查，这样它就可以作为只读属性出现在IDE代码辅助对话框中（这有点酷）

为了理解mixin，一种非常好的语言是Scala。语言本身可能不适合你，但mixin是语言中重要且广泛使用的一部分。不管怎样，这就是我得到初步理解的地方，它似乎很有效。这是一个比直接OOP继承等更不严格、更灵活的概念

好问题，我喜欢探索这些东西。你一定很喜欢这门课。
不，混音应用不正确

Person=>类扩展Person{…}
是基本继承，可以相应地实现：

class GreetingPerson extends Person {
    sayHello() {...}
}

如果有多个不相关的类应该具有相同的方法集，请考虑应用原理。
对于其余的情况（例如，不能根据上述原则重构的多态性），mixin可以应用于以下任一原型：

function mixin(obj) {
  return function (target) {
    for (const key of Object.getOwnPropertyNames(obj))
      if (key !== 'constructor')
        target.prototype[key] = obj[key];
    return target;
  }
}

class GreetingBeing {
  sayHello() {...}
}

const Person = mixin(GreetingBeing.prototype)(class Person extends Biped { ... })

// or for ES.Next,
// @mixin(GreetingBeing.prototype)
// class Person extends Biped { ...}

或例如：

class Person extends Biped {
  constructor()
    super();
    Object.assign(this, GreetingBeing.prototype);
  }
}

请注意，
mixin
helper/decorator不执行多重继承。它所做的只是将自己的可枚举属性从
GreetingBeing.prototype
复制到
Person.prototype
）
我真的不明白
问候语和
作业的意义。它们只定义空方法。只要使用
类WorkingPerson扩展Person
我也这么认为。但是如果要为Person类创建mixin，它们会是什么呢？我不喜欢mixin。如果我真的需要多重继承，@AjayH这个问题没有包含一个需要混合的例子。事实上，类mixin在JS中并不流行，并且通常表明类设计存在问题。因此，这里有一个问题：例如，在Scala中，当您检查类型时，您会得到“类与mixinclass”（“with”是使用mixin功能的关键字）。因此，您可以轻松区分未混合类和混合类。类似的东西在JS中是否也存在？@TimConsolazio-Nope。语言中不支持混合/特征，只有他/她自己能与它们结合。在TypeScript中，可以在编译时（而不是运行时）指定与接口的这种关系，比如
@mixin（BazMixin.prototype）类Foo extends Bar实现BazMixin{…<代码> >但这可能会导致打印问题，因为Mixin由于当前的限制而没有从打印脚本本身得到爱。@ SAMSON是一个风格问题。是的，我考虑这个默认位置。<代码> const <代码>的目的是防止一个变量的意外重新分配，所以在重新分配不是I的情况下使用它是合理的。已分配。通过这种方式，可以识别发生重新分配的代码，这有时会有所帮助。您可以看到
let
，并期望稍后将其分配。在任何其他情况下，都不清楚
let
应优先于
const
。我假设有JS风格的指南可以用另一种方式解决此问题。
getOwnPropertyNames
还返回
构造函数
。因此
mixin
函数将覆盖目标对象的构造函数。
mixin
函数无法正确复制getter。通常需要使用和