根据uiEvents和uiProperties新增add接口修改Form和List的视图

旁观者清， @bobshen 的思路确实是偏的，但 @Exodia 专注于对一个既成的论点进行辩解，而不是对整个思考的方向给出建设性的意见，没有提出比较系（zhuang）统（bi）性的论断，这对事情的解决还是双方的成长都没啥益处……

这个事情是这样的， **事件** 这个东西，它是一种实现层面的事，比如我们有这样的需求：

> 等用户选了一个复选框时，展开一个面板

对于这个事，我们可以通过`change`事件，自然也可以用`setInterval`轮询，甚至在某些场景下可以通过ActiveX等从驱动层面来监控鼠标、键盘，这都是 **实现** ，而事件是其中一种

而在我们说 **继承** 、 **重写** 、 **子类去除父类功能** 这些话的时候，我们面对的是 **设计** 层面的东西，这是 **实现** 的上游，所以用 **实现** 去左右 **设计** 这是不对的

针对我们在讨论的这个问题，将之提到 **设计** 的层面， @bobshen 表述的问题我重新表达下：

1. 子类需要对父类的一段逻辑作修改
2. 子类需要去除父类中已经实现的一段逻辑

看上面的表述，这里没有涉及任何 **事件处理函数** 这样的词汇，但表达的意思事实上就是一样的

再反过来，你看到上面2条的表述时，你们会怎么样去设计和实现这个需求，我想最直观的必定是 **父类实现一个方法，子类重写这个方法** ，其中去除父类逻辑就是把方法置为空函数

再往下看，这里既然通过 **方法** 这个事物来表达 **业务逻辑** ，那么在 **面向接口** 的思想之下，这个方法应当是 **与任何实现无关** 的，现结合前面说的 **事件是一种实现** ，自然推导出这个方法不应该和事件有所关联

那么到这一步以后， **事件处理函数** 又去哪里了呢？它一定是作为一种 **内部实现** 的产物，可能在原型上作为 **私有** （注意是私有）方法，也可能是闭包内的函数，但总而言之一定是私有的。而有被子类修改需要的，作为 **逻辑** 通过 **方法** 开放出来供重写

这就好比，你需要看到家里和客厅的电视机（逻辑），就要打开门（事件），但是当你不想看到客厅的电视机（去除逻辑）时，你要做的不应该是把门给封上（解绑事件），而是把电视机给搬走（重写方法）