====基于监听的事件处理
本质上是一种设计模块,是一种交互方式。
前提是要创建监听对象,然后设置给事件源。
结构上,事件源有一个监听对象表,当事件发生时去查表,找出监听对象,然后根据协议,调用监听对象的方法。
比如在win32上的观察者模式的实现,自己写一个协议类,然后让事件源持有这个协议类的对象,在适当的时候事件源调用协议类对象的函数,并且要实现协议类的子类,并设置给事件源。
比如在ios中,定义一个协议,再继承协议写一个子类,再把子类设置给事件源的id<ourprotocol> delegate。
比如android里面给一个按钮设置一个监听器,比如可以直接new一个接口对象,在对象里面实现接口的方法。
推导发散:
事件源只知道交互类的抽象,所以可以设计成接口或者协议。
adroid有interface,ios用protocol(协议)来表示接口的概念,而c++只能自已来组织这个概念。
android和ios的sdk都定义了一些接口类,可直接使用。
====基于回调的事件处理
本质上是接口(协议)的使用,谁发事件就由谁来处理,或者由它的上层容器来处理(自产自消)。
前提是,事件源或者它的上层容器要事先继承了某些协议(很多sdk的ui类本来就继承了特定协议,可以直接使用),然后处理者要实现协议里面的方法。
结构,自产自消,自己实现协议接口,实现处理。
推导发散:
事件是不是继续抛给上层处理,可以用返回值来表示(比如返回false是说上层还要作处理),在自己设计的ui框架里面也经常这样做。
====事件(消息)处理器
本质上只是个输入处理。前提是能给这个输入处理机构发送输入,这个机构也要有处理的触发时机。结构上常常是阻塞等待事件,拿到事件后分派处理事件,然后继续等待下一个事件。
设计的例子有:android里面的handler、基于win32的消息处理循环、ios里面的runloop。
推导发散:
发送的事件是同步处理还是异步处理,跟具体的设计有关,但要弄清楚。
在对象的世界里面,事件处理器应该是一个对象,并且处理函数应该是可以被重写(自定义),而发送事件应该是调用事件处理器的方法来完成。
本质上是一种设计模块,是一种交互方式。
前提是要创建监听对象,然后设置给事件源。
结构上,事件源有一个监听对象表,当事件发生时去查表,找出监听对象,然后根据协议,调用监听对象的方法。
比如在win32上的观察者模式的实现,自己写一个协议类,然后让事件源持有这个协议类的对象,在适当的时候事件源调用协议类对象的函数,并且要实现协议类的子类,并设置给事件源。
比如在ios中,定义一个协议,再继承协议写一个子类,再把子类设置给事件源的id<ourprotocol> delegate。
比如android里面给一个按钮设置一个监听器,比如可以直接new一个接口对象,在对象里面实现接口的方法。
推导发散:
事件源只知道交互类的抽象,所以可以设计成接口或者协议。
adroid有interface,ios用protocol(协议)来表示接口的概念,而c++只能自已来组织这个概念。
android和ios的sdk都定义了一些接口类,可直接使用。
====基于回调的事件处理
本质上是接口(协议)的使用,谁发事件就由谁来处理,或者由它的上层容器来处理(自产自消)。
前提是,事件源或者它的上层容器要事先继承了某些协议(很多sdk的ui类本来就继承了特定协议,可以直接使用),然后处理者要实现协议里面的方法。
结构,自产自消,自己实现协议接口,实现处理。
推导发散:
事件是不是继续抛给上层处理,可以用返回值来表示(比如返回false是说上层还要作处理),在自己设计的ui框架里面也经常这样做。
====事件(消息)处理器
本质上只是个输入处理。前提是能给这个输入处理机构发送输入,这个机构也要有处理的触发时机。结构上常常是阻塞等待事件,拿到事件后分派处理事件,然后继续等待下一个事件。
设计的例子有:android里面的handler、基于win32的消息处理循环、ios里面的runloop。
推导发散:
发送的事件是同步处理还是异步处理,跟具体的设计有关,但要弄清楚。
在对象的世界里面,事件处理器应该是一个对象,并且处理函数应该是可以被重写(自定义),而发送事件应该是调用事件处理器的方法来完成。