zoukankan      html  css  js  c++  java
  • Mentor规范

    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提的新概念已经够多了,所以也没有推。
    ----按苦茶的建议,把它记录一下。

  • 相关阅读:
    (最小路径覆盖) poj 1422
    (匈牙利算法) hdu 2119
    (匈牙利算法) hdu 4185
    (匈牙利算法) hdu 2063
    (匈牙利算法)hdu 1281
    (匈牙利算法DFS)hdu 3729
    (01 染色判奇环) hdu 3478
    (多重背包)poj 1276
    (判断欧拉回路)poj 1368
    (差分约束) hdu 1384
  • 原文地址:https://www.cnblogs.com/jkisjk/p/mentor_notice.html
Copyright © 2011-2022 走看看