霸榜GitHubTrending的设计模式教程出纸质书啦-技术圈

设计模式本身是一种通用场景的解决标准和方案，而不是实际场景开发落地的指导手册。这种通用的解决标准和方案是研发人员在大量的项目中验证和提炼的结果，如果只是学习理论知识，没有经历过大型的项目开发，则很难理解和使用设计模式。

▊ 为什么使用设计模式

首先，不使用设计模式的理由有很多

l 这个需求很简单，不用设计模式一样可以实现；

l 用设计模式浪费时间，无法满足工期要求；

l 想不到用哪种设计模式，即使知道也不会用。

但如果是一位有追求的程序员，愿意看到自己的代码是一堆if…else吗？如果每个模块的功能逻辑实现都是靠复制粘贴，功能上线后一旦出现Bug，很难及时发现和解决问题。

除了个人对代码质量追求的因素，还有业务快速发展和产品功能迭代的需求因素。如果程序没有经过良好的设计，只是为了应付一次紧急的需求而东拼西凑开发的，接下来的日子就是没日没夜地修修补补。

好的功能设计可以应对快速的需求迭代，在迭代开发的同时不需要大量改动代码。就像火车加一节车厢不需要改动整列火车，插线板可以支持随时插入各种功能插头，签字笔没墨水了可以更换笔芯等一样。对应这样的代码更像是有了一个标准接口，服务是可插拔的。

整体的服务功能更像是定义好的机器，所有的功能逻辑都像插入的一个个模块。这样的编码方式就会变得非常易于维护，同时也符合设计模式的思想。设计模式本身来自建筑学，而编码逻辑按照建筑学的方式进行，也就满足了设计模式的基本原则：做出一个可扩展、易维护、好管理的工程代码。这就是为什么应该使用设计模式开发业务需求。

▊ 设计模式的落地经验

很多东西即使摆在我们面前也看不见，就像有句话：“人生没有选择，很多选项只是摆设。”

为什么会说到这些呢？因为有些程序员是有视觉盲区或知识盲区的，主要因为程序员的工作是在承接产品需求，除此之外对业务发展、运营思路、ROI、KPI、GMV、DAU等数据是不关心或关心不到的。

如此一来就会导致一个问题，研发人员和产品经理在对接需求时，虽然在某种程度上达成了共识，但可能某些时候是存在一些目标差异的。而这个差异就是研发人员在做程序设计实现时，是否可以为业务发展和产品迭代留出相应的扩展，以及是否存在过度设计。

所以，当面对一些较简单的业务功能时，产品经理和研发人员之间并不会产生矛盾；一旦面对复杂的和快速迭代的场景需求，简单的实现可能就会变得非常麻烦，从而造成矛盾。而研发人员理解的业务经验往往也驱动着他们最终的编码实现。

使用设计模式并不像解答数学题一样有固定的公式可以套用。设计模式提供的是面对各种复杂场景中常规的解决方案，具体到实际业务中，其逻辑实现是千差万别的。所以，在学习的过程中不能生搬硬套，要活学活用。可以找一些if…else特别多的场景，尝试通过设计模式优化代码，这样能真正学会设计模式。

同时，研发人员不仅要关注自己的编码，还要多参加业务人员、产品经理、运营人员的会议，多方面了解业务需求，才能构建出更加合理的程序。

▊ 设计模式该怎样学

为了更好地接受设计模式的思想，避开理论设计模式中的简单模型案例，从真实的业务场景中提取相应的开发需求，作为学习指导思路的案例，推荐你看下小傅哥的新书《重学Java设计模式》。

小傅哥的重学Java设计模式文章全网阅读超500万次，持续霸榜GitHubTrending！让你能真真切切地感受到设计模式的魅力。当设计模式的思想与自己的开发思路融合后，再勤加练习，就能在设计模式的基础上构建出更加合理的代码。

▊ 全网爆文【字节跳动总结的设计模式】的作者纸质书《重学Java设计模式》终于正式出版

京东计算机新书榜TOP1

本书作者：付政委（小傅哥）

一线互联网 Java 工程师、架构师，开发过交易、营销类项目，实现过运营、活动类项目，设计过中间件，组织过系统重构，编写过技术专利。不仅从事业务系统的开发工作，也经常做一些字节码插桩类的设计和实现，对架构的设计和落地有丰富的经验。在热衷于Java语言的同时，也喜欢研究中继器、I/O板卡、C#和PHP，是一个技术活跃的折腾者。常逛GitHub，乐于分享技术文章。

沉淀、分享、成长，让自己和他人都能有所收获！

▊ 这本书适合哪些读者？