狗叫了 主人醒了 小偷吓跑了(二)
之前的一篇文章，同样的题目只是作了个引子，并没有作实质性的讨论。现在逐步讨论这道题目。狗叫了，主人醒了，小偷吓跑了。很形象的一个事情，如何使程序来表达它呢？如何考虑可扩展性呢？
深入的想一下，狗叫了是一个事件，主人醒了是一个结果；继而主人醒了是一个事件，小偷吓跑了又是一个结果；更进一步是否存在小偷吓跑了作为事件的后继结果呢？结论是很显然的。那么这样分析就很简单了，以事件作为驱动便顺理成章。
理次深入一下，狗叫了，是否有原因呢？狗叫是否是狗的自然属性呢，狗叫和主人醒是否可归结为同一事件属性呢？这个显然不合理。如果狗叫是原始属性的化，那么主人配便是触发事件，然后小偷吓跑了又该归结哪一类事件呢？
想到这里，于是我们的设计就有一个轮廓了，有一样东西叫事件，这些事件会触发一些东作的发生。这是核心，其它都基于这个来完成。
class BaseEvent {
virtual int actionPerform() = 0;
}
class DogEvent {
int actionPerform() {
….
}
}
….
这样似乎还缺了些东西，与事件绑定的动作，这个动作不一定是一个，那么它应该维护一个链表动作，只需要在对应Event上进行挂接就可以了。
因此修改后的BaseEvent变为:
class BaseEvent {
private:
action* action_list;
virtual int actionPerform() = 0;
}
是的，这样的确可以解释很多东西了，但是仍旧有些牵强。因为事件作动作，似乎并不合理。事件是单纯的事件，它不应该有监听的功能，也不应该有作什么动作的功能。顺着这条思路我们似乎缺少一个监听功能的监听器。由此有了如下思维的扩展。
class EventListener {
BaseEvent *event_list;
Action * action_list;
int actionPerform(Event e) {
switch (e) {
case ……
……..
}
……..
}
这样似乎逻辑更清晰的多了。可扩展性也是显而易见的。当然，许多地方为我为提供了现呈的东西，但深入思考一下这些机制，是很有益处的。
各位读者，如果您读到这里是否能够顺着这种思路更进一步的去思考它的逻辑结构呢？
thx
张久安
If you enjoyed this post, make sure you subscribe [...]
