在QWrap群里讨论时继承或实现或装饰时，讲到了自己心中的Mentor规范。
JS原生的继承机制不完善，各种继承五花八门，看得有点厌倦，所以决定抛开继承，用mix来解决此类问题。
N年前草拟了一个所谓的mentor(顾问)规范：
mentor是一个对象，而不是一个Class。
假设obj是一个{}，mixin(obj,mentor)后(由于{}是干净的，所以这时是无冲突移植)，
obj正常拥有mentor的所有功能。
对于有冲突移植，由移植者担负后果
如果一个ClassA满足: "new ClassA(...)的结果是一个mentor"
那么也说这个ClassA满足mentor规范。
mixin(obj,mentor)----这里只是mixin，意为：obj只学习mentor当时所具备的技能，并且切断obj与mentor的constructor之间的关系...
假设mentor里的某个方法用到了this.constructor，那它就不符合mentor规范了。
因为，mix后的obj.mentorMethod1()中的this成了obj，而不是之前的那个mentor。
自己开发的几个组件，都抛弃了继承，而采用了Mentor机制。例如Effect与Anim，Anim并不是Effect的子类，而只是请过Effect来当顾问。
不过，Helper+Wrap+Retouch+Apps，QWrap提的新概念已经够多了，所以也没有推。
----按苦茶的建议，把它记录一下。