需求到代码的距离有多远？也许很近，就在转角的街区，也许很远，就像6级专家与1级编码工的距离，取决于你的代码是如何实现的。

先来看一个简单的需求：网口状态down时删除路由表项。

非常简单的一种实现：

int link_down()

{

do_something();

delete_route(); //删除路由

}

需求与代码的距离如此之近，近的来不及反应就扑面而来。

不久，另外一个模块的人找你来了，说在网口状态down的时候也要把arp表项删除，希望在link_down接口里调用下delete_arp。

没问题，你非常快速的完成了功能，获得了大家的掌声与赞赏。

int link_down()

{

do_something();

delete_route(); //删除路由表项

delete_arp(); //删除ARP表项

}

再来看另外一个稍有经验的人是怎么想着：要是再有其他模块想要在link down的时候做点事情，要我添加代码，岂不烦死了。

于是，他开发了一个注册回调通知的代码，放在link模块，由于代码较多，耗时较长，他被项目经理和ARP模块的人骚扰了好几回。他完成后的代码如下：

struct link_notify

{

int (*notify_func)(void *, unsigned long);

unsigned long para;

struct link_notify *next;

};

struct link_notify *link_notify_head;

int link_notifier_register(struct link_notify *notify)

{

notify->next = link_notify_head;

link_notify_head = notify;

return 0;  

}

int link_down()

{

do_something();

link_list = link_notify_head;

while(link_list)

{

link_list->notify_func(para); // 调用注册的通知函数

link_list = link_list->nexxt;

}

}

代码完成后，他酷酷的对ARP模块的人说，你要就自己注册吧，别来烦我。

还有另外一个他，想着既然link down的时候需要通知很多模块处理信息，那么在link up的时候也是需要通知很多模块处理很多信息，还有其他很多事件状态变化也需要通知。于是，他把notify从link模块移出来，变成了一个独立的小模块。怎么移出来，参考另外一篇文章：《一种典型C语言开发思维及其可能的问题》

还有另外一个他，想着既然事件通知这种机制很多地方都使用到了，那能不能归类总结一下，作为一个通用的解决方案呢，于是，他把事件通知总结为一种设计模块，他是谁？他就是GOF( 《设计模式》一书的4个作者）。

需求到代码的距离，取决于你是谁，怎么实现你的代码。