浅谈设计模式

作为一个苦逼码农，请先回顾自己是否遇到过以下场景：

 1.我要实现的这个特性中有一些被频繁使用的代码，并且在其它特性中也被用到了，我不想总是做重复的事，那样费力且容易出错，因此需要一种方法能把这些稳固的代码抽象出来。 

2.这两个模块耦合太紧密了，代码一团糟，你中有我，我中有你，真令人抓狂！有什么办法彻底解耦吗？

 3.有一位兄弟的代码经过测试功能无误，但他的实现思路很奇怪，可读性差。我有更好的方法，但是必须首先说服他接受我的意见，我该拿出怎样权威的理由证明给他看呢？ 

4.常听到有人抱怨说软件实现太灵活了，每个人都有不同的思路。那么如何才能让一个团队的代码看起来犹如同一个人写的那样，具有良好的可读性和可维护性呢？ 

Talk is Cheap，show me the code! 先来看一个例子：当一个接口被删除之后，在引用它的模块中也要删除对应的记录。 一个新手可能会写下这样的代码：

 unsigned int funcx_remove(const char name) {

 struct nic_t * funcx = nic_get(hash(name)); / 删除对应模块的entry /

module1_del_entry_for(funcx); 

return nic_free(funcx);

 }

 目前看，这样做没有什么问题。但有一天，但是你还没有舒服几天，就收到一个问题单，说module2/module3里对应于funcx的内容没有删除！Oh，天哪！你认为不应该再这样下去了。于是你想出来一个妙招：他强由他强，清风拂山岗；他横任他横，明月照大江 

在系统中构造了一条“事件通知链”，谁对删除funcx这个事件感兴趣，就把自己的处理动作挂到链上。这样一来，funcx_delete()就不再和具体的模块耦合，问题单不会再压到你的头上。

 unsigned int funcx_remove(const char *name) {

 struct nic_t *nic = nic_get(hash(name)); / 把事件通知到系统 ，不关心接受者都有谁 */ 

nic_event_notify(funcx_REMOVED, nic); return nic_free(nic);

 }

 然后你放一个注册接口出来，谁对这个事件感兴趣就自己注册吧，别再烦我 

void register_event_notifier(struct notifier_hook_t notify);

设计模式要干啥？设计模式的本质是职责的分离，职责不是天生的，如何去分离职责？这才是发力的重点，培养对“职责”的敏感度和基本思考技巧，设计模式要做的，就是把代码中相对稳定的部分和剧烈变动的部分解耦，从而将变化对代码产生的影响局限在小范围内。

上个例子中就是一个观察者模式，把事件发生，和对应的动作分离，事件发生了，我就根据对应的注册信息通知到所有关注者，而具体的动作，由关注者自己做。 经典的Gof设计模式有三类二十三种，它们可以分为：创建型，结构型和行为型，这篇文章作为开始，陆续总结，但是要提醒的是，不要试图在你的代码中全方位地套用设计模式，熟练地运用几种模式来解决问题就足够了。模式只是手段，用高内聚，低耦合的代码为业务服务才是每一位程序员追求的目标。