关于回调函数，事件模型

首先，我也是经历了“认为回调函数比事件模型好”，“认为事件模型比回调函数好”，这两个阶段都走过才来说这样的话的。其实“回调函数”和“事件模型”可以作为架构方式的两个标志。这里，我就单单说说它们的优缺点吧。

 

回调函数

优点：

1.没有内存泄漏问题

2.书写简单，一个方法的回调函数数量和意义是固定的，不需要刻意查找需要的回调函数名称

3.你无法对同一个内容加上两个回调函数，可以避免重复添加的问题

4.回调函数的参数列表比较灵活，可以直接写，而且是固定的，写错了执行时会报错，方便排错

5.回调函数以及它的参数是固定的，多了少了都不行，如果对方和你不同可以马上知道，方便协作。

 

缺点

1.回调函数不能保持引用，可能函数还没有执行就被回收了，可靠性较低。

2.每次增加内容，都需要修改所有函数的参数列表。添加新的回调函数则更难。

3.你无法对同一个内容加上两个回调函数，功能受到很大的限制。

4.回调函数的参数列表除非看代码或者帮助（注释）是不知道的，使用较麻烦。

5.回调函数以及它的参数是固定的，多了少了都不行，对方必须跟着你脚步走，不利于并行开发。

 

事件模型

优点：

1.使用不当，会造成内存泄露问题。

2.事件可以方便地修改。添加新事件，修改数据类型，并在不同的地方使用。

3.你可能对同一个事件监听两个事件函数，而且事件可以进行传递等等操作，拥有许多便捷的特性（诸如显示对象的冒泡）

4.事件无论是事件类型还是事件传递的数据类型都可以在编译期间检测，而且拥有代码提示，容易使用。

5.事件很自由，即使没有接受方也可以发送，非常适合并行开发。

 

缺点：

1.只要使用强引用，函数最终都可以执行，可靠性高（当然某些特别的诸如SharedObject那是特殊情况就算了）

2.每个事件类型可以传递的数据类型是固定的，为适应新的情况增加新的事件会增加很多代码。而且还需要移除等等操作，设置属性也需要单独的代码。

3.你可能会不小心对同一个事件监听了两个事件函数，造成重复调用。而且可能会在不需要的时候触发事件。

4.事件类型多到了一定程度，反而会不知道选择哪个事件类型才能找到想发送的特定事件。所以不可能一种情况对应一个事件类型。但容易用Object来通用化的话，它原来的优势又没了。

5.事件即使没有接受方也可以发送，因此，你根本不知道对方是否成功接受到了事件。

 

将4部分的1，2，3，4，5对照起来应该能表达出我的意思了。

我没什么意思。也就是“看情况”罢了。当然，一定要强制只用一个的话，我选事件。

 

但简单地说谁就好谁就差的话，真的有认真考虑手边的事情吗？程序是不能空谈的，装B的话，则更不用说了。