需求到代码的距离有多远？也许很近，就在转角的街区，也许很远，就像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个作者）。
需求到代码的距离，取决于你是谁，怎么实现你的代码。