software_base-event_drive-listener_msgloop

====基于监听的事件处理
本质上是一种设计模块，是一种交互方式。
前提是要创建监听对象，然后设置给事件源。
结构上，事件源有一个监听对象表，当事件发生时去查表，找出监听对象，然后根据协议，调用监听对象的方法。
比如在win32上的观察者模式的实现，自己写一个协议类，然后让事件源持有这个协议类的对象，在适当的时候事件源调用协议类对象的函数，并且要实现协议类的子类，并设置给事件源。
比如在ios中，定义一个协议，再继承协议写一个子类，再把子类设置给事件源的id<ourprotocol> delegate。
比如android里面给一个按钮设置一个监听器，比如可以直接new一个接口对象，在对象里面实现接口的方法。
推导发散：
事件源只知道交互类的抽象，所以可以设计成接口或者协议。
adroid有interface，ios用protocol（协议）来表示接口的概念，而c++只能自已来组织这个概念。
android和ios的sdk都定义了一些接口类，可直接使用。


====基于回调的事件处理
本质上是接口（协议）的使用，谁发事件就由谁来处理，或者由它的上层容器来处理（自产自消）。
前提是，事件源或者它的上层容器要事先继承了某些协议（很多sdk的ui类本来就继承了特定协议，可以直接使用），然后处理者要实现协议里面的方法。
结构，自产自消，自己实现协议接口，实现处理。
推导发散：
事件是不是继续抛给上层处理，可以用返回值来表示（比如返回false是说上层还要作处理），在自己设计的ui框架里面也经常这样做。


====事件（消息）处理器
本质上只是个输入处理。前提是能给这个输入处理机构发送输入，这个机构也要有处理的触发时机。结构上常常是阻塞等待事件，拿到事件后分派处理事件，然后继续等待下一个事件。
设计的例子有：android里面的handler、基于win32的消息处理循环、ios里面的runloop。
推导发散：
发送的事件是同步处理还是异步处理，跟具体的设计有关，但要弄清楚。
在对象的世界里面，事件处理器应该是一个对象，并且处理函数应该是可以被重写（自定义），而发送事件应该是调用事件处理器的方法来完成。