设计模式是不是一件脱裤子放屁的事

    我这条老程序狗也曾有年轻的时候，当年毛色鲜亮，油光水滑，60级经验已满，正准备升级转职。跟职业训练师聊过后接受任务：学习名字很屌的专家级技能书《Head First Design Patterns》（中文版就是名字很不屌的《设计模式深入浅出》）。上当当网支付80金币，数天后NPC快递员送来任务物品，于是沐浴焚香，恭恭敬敬的翻开第一页，只见扉页上写着“欲练神功，必先自宫”。

    等等！别再胡扯下去了，这本如今被奉为设计模式圣经的书，除了封面那个长得好像东方不败的洋妞，跟《葵花宝典》没有半毛钱关系。然而在苦读数小时后，老狗产生了跟任我行当年初读《葵花宝典》一样的想法：“这书是要人断子绝孙的！”

    在当年的我看来，设计模式这事根本就是少数精英策划的，企图灭绝程序狗种族的大阴谋！精英们就是嫌程序狗们还不够苦逼，变着法儿的再给大伙儿增加工作量，企图累死单纯的程序狗们！不信请看接口（interface）这个阴险的设计，它除了让你多写几行代码，还能干嘛用？整个设计模式就是把两行程序能搞定的事，变成二三个接口加三五个类才下的来地。以至于诚惶诚恐的小程序狗们都不敢直接new个对象，不整个抽象工厂加单例模式都不好意思Hello World了！

    于是我对着山谷（不是令狐冲当年面壁那个）怒吼：“为了啥！你们这是为了啥！”

    山谷里传来圣贤们的回答：“为了解耦 耦 耦 耦……重要的事情说三遍”

    如今漫长的十年已过去，我的狗毛已经斑秃，尖牙已经磨平，变成一条得道高狗的模样。十年来，这个喧嚣的世界不停向我脑海里灌注各种声音，一会儿敏捷开发，一会儿轻量级框架……在这些杂音背后，圣贤们像个被卡坏的留声机，不停在我脑海里播放这两个字“解耦解耦 解耦 耦 耦 耦……重要的事情说三遍”

    于是，老狗我缕一缕颌下的白毛，跟你们这些小狗们说：“尔等欲识设计模式，请先识解耦”

    君可知二十三种设计模式，大部分是为了实现解耦吗。解耦就像把纠结成一团的狗毛一根根缕顺、理清、分开，再织成一件件能单独穿上、合理搭配的狗毛背心、狗毛裤衩、狗毛西服、狗毛小蝴蝶结、狗毛小袜子……你们看，这是多么伟大的一件事啊！在程序狗界，这就像原始人类开始穿衣服一样具有划时代的意义！

    请诸位回顾一下设计的六原则，仔细揣摩，从每一条原则里都能剥出解耦这两个字来。

    开闭原则（Open Close Principle）：对扩展开放，对修改关闭。当系统功能发生改变时，不去修改原有的功能类，而是创建一个新类去替换原有的类。如何做到这一点？利用接口规范类的行为，与具体的实现类解耦！

    里氏代换原则（Liskov Substitution Principle）：任何基类可以出现的地方，子类一定可以出现。这一条看起来是讲继承复用的，与解耦无关。实际上如果衍生类可以完全替换基类，也就实现了类的解耦，在任何地方都能使用不同的衍生类。

    依赖倒转原则（Dependence Inversion Principle）：对接口编程，依赖于抽象而不依赖于具体。这条不废话，就是抽象与实现解耦的意思！

    接口隔离原则（Interface Segregation Principle）：使用多个隔离的接口，比使用单个接口要好。降低接口的耦合！

    迪米特法则（最少知道原则）（Demeter Principle）：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。实体之间解耦！

    合成复用原则（Composite Reuse Principle）：尽量使用合成/聚合的方式，而不是使用继承。继承本身就是一种强耦合关系，为了解耦尽量少用！

    少年们，请听我一言！在学习设计模式时务必牢记以上六原则，如果对任一种模式产生了疑问，请仔细思考一下，如果采用其他方式，是否违反了其中一条或数条原则？

    如此，也许可解答各位在初识设计模式时的困惑，请相信：先贤们真的，真的，真的不是要脱裤子放屁！

---

更多文章欢迎关注我的微信公众号：junior9919

扫码立即关注

文章看爽了就请打个赏吧