无用的设计模式-上篇
点击关注“有赞coder”
获取更多技术干货哦～
作者：吕浩
部门：有赞美业
提到设计模式，有一个非常有意思的现象： 理论学习中，几乎所有的开发人员都认为它非常有用很重要。 工作实践中，绝大部分开发人员在项目中找不到合适的应用场景。 设计模式学了一遍又一遍，却毫无用武之地。大概设计模式最好的归宿，就是存在程序员的深深的脑海里。
关于本文
一、设计模式到底是什么？
1.1 设计模式诞生背景
1.2 设计模式的前世
1.3 设计模式的今生
二、我们需要设计模式吗？
2.1 经验之谈，依然有效
2.2 业务需要设计模式
近10年来，软件生产效率有了巨大的提升。抛开硬件的因素，很大程度上是因为面向对象的普及，以及配套工具体系（例如框架）的完善。以至于在日常开发中，很多人会认为框架解决了所有问题，业务不过是CRUD。
行业领域的专业性 商家场景的多样性 业务规则的不一致性 个性需求的不确定性 需求难以协调的刚性
三、怎么学习设计模式？
不会用，对设计模式不熟悉，不知道该怎么应用。 用不上，业务中一直找不到合适的场景，不知道用在哪。
3.1 解构设计模式
名称：模式名称是帮助我们理解记忆，方便沟通交流的标识。它是场景的简称，场景描述了问题产生的背景。 问题：它是场景中想要达成的目标与现状之间的落差。通常一个模式中的问题，代表的是一类问题，不特指某一个具体的问题。 方案：针对模式中的问题，存在已经被反复实践验证过的最佳解决方案。解决方案并不描述一个特定而具体的设计或实现，具有一定普适性。
割裂看待各个模式，用熟悉的场景去套用模式 有创建对象场景，立即会想到用工厂模式 本地引用远程服务场景，想到代理模式 String/Integer常量池，线程池，连接池，想到享元模式 全部心思都在解决方案本身上，陷入细节不可自拔，各种方案越看越迷茫 适配器、装饰模式的区别 策略、桥接模式也有相似之处
问题=>模式的思路来分析下在这个过程中可能会遇到的问题：创建实例过程太复杂? 为什么复杂?是依赖对象太多？有办法解耦吗? 是对象本身属性多？可以按需初始化吗？ [建造者模式]是要创建不同类型实例的逻辑太复杂？有办法将创建行为统一起来吗？ [工厂模式]创建实例成本太高？ 为什么太高？有优化空间吗？复制对象替代创建新行为可行吗？ [原型模式]延迟创建可以吗？单例可行吗? 实例共享可行吗？ [单例、享元模式]
3.2 小结
四、面向对象设计原则及共识
4.1 面向对象编程3大特性
is-a) = 实现( like-a) > 组合( part-a) > 聚合( contains-a) > 关联( has-a) > 依赖( use-a)。泛化，比较好理解，是类与类之间或者接口与接口之间的继承关系。
实现，也比较常见，类与接口之间的关系。
组合，是一种强关联，强调部分是整体不可分割的一部分，具有相同的生命周期。例如手是身体的一部分。
聚合，是一种组合稍弱的强关联，强调个体相对于集体的独立性，个体组成了集体，两者生命周期是独立的。例如独立个体的人，聚在一起，形成了各种团体组织。
关联，强调的是拥有关系，是实际存在的逻辑关联。例如夫妻双方，互相为对方的配偶，两者之间关系为关联关系。 - 依赖，是一种耦合度较低的关系，这种关系一般是偶然性的、临时性的。例如我们使用手机打游戏，我们依赖了手机，本质上我们跟手机是不存在逻辑联系的。
is-a的静态关系。继承同时也具备复用属性与行为的能力。like-a的动态关系，在运行时体现出不同。4.2 面向对象设计7大原则
依赖倒置原则：面向接口编程，不要针对实现编程。实现意味着应对变化的能力下降，尽量延迟到调用时再具体化。
开闭原则：对扩展开放，对修改关闭。比较好理解，扩展新增引入的风险相对修改更可控一些。修改往往意味着，系统扩展性不够。
里氏替换原则：继承父类的目的是为了复用。高质量的继承关系，是衍生类可以完全替换掉基类，并且系统的行为不受到影响。如果子类不能完全替换父类，说明继承是不彻底的，复用的目的就没有达到。
单一职责原则：一个类应该只承担一个职责。承担的职责过多，职责之间可能会相互耦合。这里最难的就是划分职责，职责必须恰如其分地表现实体的行为。比如用户账号可以修改基础信息，会员可以持有会员卡。如果不加以区分，只抽象一个用户实体包括所有的行为，显然是不合适的。
接口隔离原则：适度细化接口，接口的行为尽量少。分治的思想，降低复杂性，系统更可控。
迪米特法则：一个类对依赖的类知道的越少越好。本质目的是将复杂度控制在一定范围内。
组合/聚合复用原则：复用即可以通过继承实现，也可以通过组合 / 聚合实现。区别在于，继承表达
is-a的逻辑关联，目的在描述结构，而不是复用。