查看文章尾部参与赠书活动
设计模式本身是一种通用场景的解决标准和方案，而不是实际场景开发落地的指导手册。这种通用的解决标准和方案是研发人员在大量的项目中验证和提炼的结果，如果只是学习理论知识，没有经历过大型的项目开发，则很难理解和使用设计模式。
▊为什么使用设计模式首先，不使用设计模式的理由有很多
l这个需求很简单，不用设计模式一样可以实现；
l用设计模式浪费时间，无法满足工期要求；
l想不到用哪种设计模式，即使知道也不会用。
但如果是一位有追求的程序员，愿意看到自己的代码是一堆if…else吗？如果每个模块的功能逻辑实现都是靠复制粘贴，功能上线后一旦出现Bug，很难及时发现和解决问题。
除了个人对代码质量追求的因素，还有业务快速发展和产品功能迭代的需求因素。如果程序没有经过良好的设计，只是为了应付一次紧急的需求而东拼西凑开发的，接下来的日子就是没日没夜地修修补补。
好的功能设计可以应对快速的需求迭代，在迭代开发的同时不需要大量改动代码。就像火车加一节车厢不需要改动整列火车，插线板可以支持随时插入各种功能插头，签字笔没墨水了可以更换笔芯等一样。对应这样的代码更像是有了一个标准接口，服务是可插拔的。
整体的服务功能更像是定义好的机器，所有的功能逻辑都像插入的一个个模块。这样的编码方式就会变得非常易于维护，同时也符合设计模式的思想。设计模式本身来自建筑学，而编码逻辑按照建筑学的方式进行，也就满足了设计模式的基本原则：做出一个可扩展、易维护、好管理的工程代码。这就是为什么应该使用设计模式开发业务需求。
▊设计模式的落地经验很多东西即使摆在我们面前也看不见，就像有句话：“人生没有选择，很多选项只是摆设。”
为什么会说到这些呢？因为有些程序员是有视觉盲区或知识盲区的，主要因为程序员的工作是在承接产品需求，除此之外对业务发展、运营思路、ROI、KPI、GMV、DAU等数据是不关心或关心不到的。
如此一来就会导致一个问题，研发人员和产品经理在对接需求时，虽然在某种程度上达成了共识，但可能某些时候是存在一些目标差异的。而这个差异就是研发人员在做程序设计实现时，是否可以为业务发展和产品迭代留出相应的扩展，以及是否存在过度设计。
所以，当面对一些较简单的业务功能时，产品经理和研发人员之间并不会产生矛盾；一旦面对复杂的和快速迭代的场景需求，简单的实现可能就会变得非常麻烦，从而造成矛盾。而研发人员理解的业务经验往往也驱动着他们最终的编码实现。
使用设计模式并不像解答数学题一样有固定的公式可以套用。设计模式提供的是面对各种复杂场景中常规的解决方案，具体到实际业务中，其逻辑实现是千差万别的。所以，在学习的过程中不能生搬硬套，要活学活用。可以找一些if…else特别多的场景，尝试通过设计模式优化代码，这样能真正学会设计模式。
同时，研发人员不仅要