后端面试38讲_23_答疑丨对于设计模式而言场景到底有多重要
你好，我是李智慧。
今天呢更新的是第二模块的最后一讲。
这一模块中我们主要讲的软件的设计原理。
今天我将会针对这一模块中的遗留问题进行总结和答疑。
并且我在最后列了一个书单，这个书单中涉及到的书可能会对你学习设计模式有一些帮助，让我们整理一下，再接着学习下一个模块的内容。
我们先来看一个同学提出的问题。
Ad为三猫的同学针对开闭原则的例子提出了这样一个观点，如果项目初始就对八台按钮进行复杂的设计，那么项目后期的维护成本也是相当之高。
我的想法是，我们这个模块是讲设计的，这些设计原则都是用来解决需求变更的问题的。
如果你为需求变更进行了设计，但是呢，预期中的需求变更却从来没有发生，那么你的设计就属于设计过渡。
如果已经发生了需求变更，但是你却没有用灵活的设计方法去应对，而是通过硬编码的方式在既有的代码上打补丁，那么这就是设计不足。
因此，是否要使用各种设计原则和设计模式去设计一个非常灵活的程序。
主要是看你的需求场景。
如果你的场景就是需要灵活，就是要各种复用，应对各种变更，那么一开始就应该这样设计。
如果你的场景根本不需要一个可复用的butter.同么你就不需要这样设计。
所以呢关键还是看场景，但是场景景会复用用，开始不需要复用。
但是是来又需要复用了，那么就需要在复用的第一个场景去重构代码，而不是等到将来困难重重，hold ld不住了再去重构。
同时，设计原则和设计模式只是让代代码起来复杂杂，毕竟一个接口看起来实现，看起来不如ELS来的直接。
但是如果习惯了这种灵活的设计，你会觉得这种设计并不复杂。
对于软件开发而言，复杂的永远是业务逻辑，而不是设计模式。
但计模式是可重重复的，可重复的东西即使看起来复杂熟悉了，就会觉得很简单。
而看起来复杂的模式就是用来解决维护困难这种问题的。
因此，正确的使用设计模式看起来复杂了。
其实维护简单了，由为关系和边界更清晰了。
你不需要在一堆强耦合的代码里搅来搅去。
真正维护成本高的，其实是那些所谓的简单设计硬编码，实现功能。
钱一发而动，全身稍不注意就是各种bug.最终呢一切都是要看场景，只有合适的设计，不存在好的设计，分析场景，根据场景进行相应的设计。
当然你要先知道有哪些设计原则和设计模式可以用在这样的场景，这就是我们这个专栏模块的目的。
另外我在第十三篇留了一道思考题。
这道思考题是这样的，父类中有抽象方法。
F抛出异常，a exception子类override负类这个方法后，想要将抛出的异常改为b exception.那么b exception应该是a exception的负类还是子类，很多人都回答正确的，但是也有一些回答是错误的。
我这里说明一下，正确答案为b exception是a exception的子类。
因为只有异常是子类使用负类的地方，开启异常的时候才能catch到这个子类。
方法的异常，也就是异常的子类才能够满足你是替换原则，能用子类替换父类。
最近几年分布式架构、大数据、区块链、物联网i技术广泛流行。
当我们说起软件开发的时候，提到的常常是这些宏大的技术架构，但是这个宏大的技术也要落实到代码上。
再厉害的技术终究要解决的是我们的业务问题。
如果不能够写出清晰简单的代码软件之间的耦合关系梳理不清楚，即使用了一些很炫酷的技术软件开发，可能还是会陷入到混乱之中。
这些年，我也曾在一些知名的企业做过各种分布式系统、大数据平台开发，这些系统本身的架构也许有很大的创新之处，但是真正使这些系统成功的依然是底层那些干净清晰的代码。
这些年，我也曾见过一些知名的架构师布道师，这些人也曾引领技术潮流，成为风口浪尖上的技术红人，不是真正能够一直走下去、走得远的，不是那些给自己安了各种厉害头衔的人，而是那些能够踏踏实实写出漂亮代码的人。
这个赚来的第二个模块就是想传达这种信息。
我们为什么要写好的代码，而不仅仅是些能用的代码，以及什么叫做好的代码，如何写出好的代码。
人类编程的历史超过半个多世纪了。
关于什么叫做好的代码，如何写出好的代码，也有很多研究有很多的经典案例和著作。
专栏中的内容，主要都是来自于这些经典的作品专栏。
零九如何使用UML建模的内容主要来自于UML精粹。
这本书其实UML本身非常简单，简单到我都觉得不值得。
专门阅读一本书去学习。
Umluml真正需要学习的是如何灵活使用UML去完成软件设计，如何用UML表达出自己的设计意图，以及在什么样的场景下，用什么样的模型图去表述自己的设计意图。
马丁福勒的这本书呢也是偏重UML的实践应用，不是讲UML语法本身如何，我的专栏文章内容只是更多的来自自己的一些最佳实践。
如何用UML完成设计文档？应该说我在十几年前得以最早抓住机会，跳出开发CRUD代码，去做一些大型系统的框架和架构开发工作。
正是因为我用UML比较清晰的表述了系统当时的状况和设计目标，打动了项目的领导，放手让我一个资历尚行的行人去做系统的架构设计，也因此改变了自己的职业发展路径。
我也期望UML能够帮你找到自己的职业跳跃之路。
专栏十一到十五篇文章，主要是讲述软件设计的基本原则。
这些内容主要来自于敏捷软件开发原则、模式与实践。
这本书作者罗伯特森马丁更知名的是它的昵称，包括大树，这本书的名字叫做敏捷软件变发。
那么全书主要讲的是设计原则与设计模式。
作者认为，我们能够进行敏捷开发，能够快速响应需求变更。
核心不在于什么敏捷开发过程和敏捷项目管理，而在于敏捷的软件设计。
如果代码一团糟，各种耦合，各种腐化，任你用什么项目管理手段都无济于事。
但是，如果你的代码灵活、强壮、易于维护和变更，可以轻松应对各种需求变更，那么敏捷的项目管理管理才能够真正带来敏捷的效果。
应该说我第一次读这本书的时候，给我的震撼是相当大的。
人们在软件开发中遇到困难，本能的是想寻找一种轻松又强大的解决办法。
什么管理方法了，外部咨询了，购买商业解决方案了，但是软件终究是存在于工程师编写的一行行的代码里。
如果不把这些代码搞清楚搞好，再好的外部支持，只怕也帮不上什么忙。
第十九篇内容则是来自于罗伯特森马丁的一本比较新的书，叫做架构整洁之道。
这本书算是包裹大树架构思想的一本书，讲述了关于架构的过往与现在关于架构的各种思想原理。
第二十篇的内容则来自于马丁福勒的另一本经典著作企业应用架构模式。
这本书是讲述企业架构模式的极大成者。
我们日常开发使用的各种技术，各种解决方案，而不过是这本书里找到来源很多业界广泛使用的技术产品。
Spring、满贝tas这些只不过是这本书里很多架构模式的一种，而同类的模式还有很多这些模式有的被淘汰，有的还在进化之中。
看这本书里的各种架构模式，然后再想想这些模式背后的技术在这些年里的起起伏伏，感觉很是沧桑。
这就是第二模块中遗留的一些问题。
无论是架构还是软件开发，终归是要落到人的身上，落到人编写的一行行代码身上。
我希望这个模块可以对你写代码，有一些好的启发与提示。