custom-ability/README.cn.md

make custom ability more easy. generate the ability which can be added to any class directly.

Note: **非枚举成员**会检查是否方法,如果是方法会启用重载机制(允许你调用原有的方法),如果是**可枚举成员**则会直接覆盖.


`AdditionalInjectionMode`:

默认模式为`all`: 当注入能力(如`MyAbility`)的时候, 会检查目标类的继承链中所有存在`$abilities`中与该类能力关联的属性(`$abilities`中的key为`MyAbility`)的类,如果存在那么就将该key(值为`MyAbility`)的该附加能力注入在该类上,于此同时`MyAbility`能力将被注入到"基"(存在附加能力的继承链中最远的那个类)类上而不是目标类上. 该模式的使用场景是:当这些附加能力依赖于该能力(`MyAbility`)的时候,那么要让所有的派生类都有效,所以必须在最远的基类上注册.

`target`模式,当注入能力(如`MyAbility`)时, 目标类的继承链上的附加能力仅在目标类上注入,而不是在对应的继承链上的类进行注入. 使用场景,当使用能力注入依赖参数进行注入的时候,比如上面的`refCountable`代码,这个时候`eventable`在注入时,应该同时在该类上注入重载这些方法,而不是注入在`refCountable`时所在的类上.

场景一(all): 当注入该能力(如`MyAbility`)的时候, 会注入该类继承链中所有直接存在`$abilities`中与该类能力关联的属性(`$abilities`中的key存在为`MyAbility`)的类. 默认

然后在附加能力使用场景1时,如果存在附加能力,那么其能力可能不会注入在指定的目标类上,而是注入在最远的基类上.然而能力标识却是在目标类上(已经修正,能力标识在基类上了)! 有点明白当时的考虑了,当这些附加能力依赖于该能力的时候,那么要让所有的派生类都有效,所以必须在最远的基类上注册.


场景二(target): 当注入该能力(如`MyAbility`)的时候,仅在注入该能力的类上执行. 使用场景, `stateable` 增加 `eventable` 支持.

* `stateable` 增加 `state` 支持时,会在`$abilities`中添加`Eventable`字段,告知当`eventable`的时候,应该如何重载`stateable`中的方法.
* 然后, `eventable`在注入时,应该同时在该类上注入重载这些方法,而不是在`stateable`时所在的类上.

为了支持场景一和二,我们需要增加一个参数,来明确附加注入的方式. `type`: inherited, direct

在场景1时候,可能在继承链上会有多次注入,因为附加能力注入的时候并没有指示附加能力已经注入的标识.再增加一个`id`参数,如果没有默认为能力名.这个是以防有多个附加能力Opt注入到同一个能力上的时候.
还需要增加一个属性来保存附加能力注入情况集中存放: `$abilitiesOpt`, `key` 为 `能力名`+`_`+`id`,如果没有`id`,那么就是`能力名`.

为options增加`id`属性,允许多个附加能力参数绑定在同一个能力上.

`export const AdditionalInjectionMode = { all: 0, target: 1}`

    // 1. 能力类在父类: $abilities 在父类, 将 opts 放在父类
    // 2. 在子类注入能力, 那么附加能力将被注入到 opts 所在的类, 因为能力类是在子类注入的, 导致重复注入.
    // 为什么要将附加能力放在 "opts"所在的类上?而不是和注入的那个类放在一起?
    // 对象状态能力在基类上,为了能使用事件能力,在对象状态的基类上,记录了对象状态使用事件的附加能力.
    // 该附加能力会重载一些对象状态的方法以使用事件能力.

如果同一个能力有多个附加处理,有的附加处理要求direct,有的附加处理要求inherited,如何搞?还有,有的附加处理在目标类上,有的在基类上.

1. `direct`模式: 直接在目标类上注入,或者改名叫`target`模式
2. `inherited`模式: 在定义附加处理的类上注入.或者改名叫`all`模式

然后,思考该在哪里注入能力?当在基类上注入附加能力的时候,如果能力注入在目标类上,那么基类上的附加能力就无法使用!
如果在基类上注入能力,似乎又违背了注入目标类的命令(可能会造成基类冲突,应该不会,因为附加能力的定义就在该基类上,尽管目前我就是这样处理的)!

目前附加能力的定义API,还不是很稳定,或者说没有想好如何定义附加能力的API.目前只有数据结构.已经想好了,增加`AbilityInjectorOptions`

一个能力可以带有若干附加能力,用来与其它能力进行协作,以`stateable`能力为例,如何让`stateable`能使用`eventable`能力,就是在启用`stateable`的时候,同时给目标类添加一个`eventable`的附加能力(名为`stateable`的),这样当启用`eventable`能力的时候,如果对应类同时存在事件的附加能力,就会被应用. API出来了,应该在`createAbilityInjector`函数添加一个参数,增加可选的附加能力选项.

* 注意: 在注入能力和以及该能力的附加依赖能力的时候,要逐一检查,是否已经有附加依赖能力被注入,如果发现有,则这些附加能力应该马上注入.
* 注意: 当能力已经被注入到目标类,并且排除了该能力的某些方法,可能导致附加能力失效(如果该附加能力依赖于该方法)!没有想好,也许可以考虑加一个参数,允许强制再次注入. 目前是在`AdditionalAbility`上添加了`required`参数,标示该附加能力必须要的方法名列表.如果发现目标类上的能力不存在这些必要的方法,就不会注入该附加能力.