最后
给大家送一个小福利
附高清脑图，高清知识点讲解教程，以及一些面试真题及答案解析。送给需要的提升技术、准备面试跳槽、自身职业规划迷茫的朋友们。
设计良好的计算机软件应该易于扩展，同时抗拒修改。
换句话说，一个设计良好的计算机系统应该在不需要修改的前提下就可以轻易被扩展。
其实这也是我们研究软件架构的根本目的。如果对原始需求的小小延伸就需要对原有的软件系统进行大幅修改，那么这个系统的架构设计显然是失败的。
尽管大部分软件设计师都已经认可了OCP是设计类与模块时的重要原则，但是在软件架构层面，这项原则的意义则更为重大。
下面，让我们用一个思想实验来做一些说明。
假设我们现在要设计一个在Web页面上展示财务数据的系统，页面上的数据要可以滚动显示，其中负值应显示为红色。
接下来，该系统的所有者又要求同样的数据需要形成一个报表，该报表要能用黑白打印机打印，并且其报表格式要得到合理分页，每页都要包含页头、页尾及栏目名。同时，负值应该以括号表示。
显然，我们需要增加一些代码来完成这个要求。但在这里我们更关注的问题是，满足新的要求需要更改多少旧代码。
一个好的软件架构设计师会努力将旧代码的修改需求量降至最小，甚至为0。
但该如何实现这一点呢？我们可以先将满足不同需求的代码分组（即SRP），然后再来调整这些分组之间的依赖关系（即DIP）。
利用SRP，我们可以按下图中所展示的方式来处理数据流。即先用一段分析程序处理原始的财务数据，以形成报表的数据结构，最后再用两个不同的报表生成器来产生报表。
SRP的应用
这里的核心就是将应用生成报表的过程拆成两个不同的操作。即先计算出报表数据，再生成具体的展示报表（分别以网页及纸质的形式展示）。
接下来，我们就该修改其源代码之间的依赖关系了。这样做的目的是保证其中一个操作被修改之后不会影响到另外一个操作。同时，我们所构建的新的组织形式应该保证该程序后续在行为上的扩展都无须修改现有代码。
在具体实现上，我们会将整个程序进程划分成一系列的类，然后再将这些类分割成不同的组件。下面，我们用下图中的那些双线框来具体描述一下整个实现。在这个图中，左上角的组件是Controller，右上角是Interactor，右下角是Database，左下角则有四个组件分别用于代表不同的Presenter和View。
在下图中，用＜I＞标记的类代表接口，用＜DS＞标记的则代表数据结构；开放箭头指代的是使用关系，闭合箭头则指代了实现与继承关系。
首先，我们在下图中看到的所有依赖关系都是其源代码中存在的依赖关系。这里，从类A指向类B的箭头意味着A的源代码中涉及了B，但是B的源代码中并不涉及A。因此在下图中，FinancialDataMapper在实现接口时需要知道FinancialDataGateway的实现，而FinancialDataGateway则完全不必知道FinancialDataMapper的实现。
其次，这里很重要的一点是这些双线框的边界都是单向跨越的。也就是说，上图中所有组件之间的关系都是单向依赖的，如下图所示，图中的箭头都指向那些我们不想经常更改的组件。
让我们再来复述一下这里的设计原则：如果A组件不想被B组件上发生的修改所影响，那么就应该让B组件依赖于A组件。
所以现在的情况是，我们不想让发生在Presenter上的修改影响到Controller，也不想让发生在View上的修改影响到Presenter。而最关键的是，我们不想让任何修改影响到Interactor。
其中，Interactor组件是整个系统中最符合OCP的。发生在Database、Controller、Presenter甚至View上的修改都不会影响到Interactor。
为什么Interactor会被放在这么重要的位置上呢？因为它是该程序的业务逻辑所在之处，Interactor中包含了其最高层次的应用策略。其他组件都只是负责处理周边的辅助逻辑，只有Interactor才是核心组件。
虽然Controller组件只是Interactor的附属品，但它却是Presenter和View所服务的核心。同样的，虽然Presenter组件是Controller的附属品，但它却是View所服务的核心。
另外需要注意的是，这里利用“层级”这个概念创造了一系列不同的保护层级。譬如，Interactor是最高层的抽象，所以它被保护得最严密，而Presenter比View的层级高，但比Controller和Interactor的层级低。
以上就是我们在软件架构层次上对OCP这一设计原则的应用。软件架构师可以根据相关函数被修改的原因、修改的方式及修改的时间来对其进行分组隔离，并将这些互相隔离的函分组整理成组件结构，使得高阶组件不会因低阶组件被修改而受到影响。
依赖方向的控制
=======
如果刚刚的类设计把你吓着了，别害怕！你刚刚在图表中所看到的复杂度是我们想要对组件之间的依赖方向进行控制而产生的。
例如，FinancialReportGenerator和FinancialDataMapper之间的FinancialDataGateway接口是为了反转Interactor与Database之间的依赖关系而产生的。同样的，FinancialReportPresenter接口与两个View接口之间也类似于这种情况。
当然，FinancialReportRequester接口的作用则完全不同，它的作用是保护FinancialReportController不过度依赖于Interactor的内部细节。如果没有这个接口，则Controller将会传递性地依赖于FinancialEntities。
这种传递性依赖违反了“软件系统不应该依赖其不直接使用的组件”这一基本原则。之后，我们会在讨论接口隔离原则和共同复用原则的时候再次提到这一点。
所以，虽然我们的首要目的是为了让Interactor屏蔽掉发生在Controller上的修改，但也需要通过隐藏Interactor内部细节的方法来让其屏蔽掉来自Controller的依赖。
OCP是我们进行系统架构设计的主导原则，其主要目标是让系统易于扩展，同时限制其每次被修改所影响的范围。实现方式是通过将系统划分为一系列组件，并且将这些组件间的依赖关系按层次结构进行组织，使得高阶组件不会因低阶组件被修改而受到影响。
LSP：里氏替换原则
==========
1988年，Barbara Liskov在描述如何定义子类型时写下了这样一段话：
这里需要的是一种可替换性：如果对于每个类型是S的对象o1都存在一个类型为T的对象o2，能使操作T类型的程序P在用o2替换o1时行为保持不变，我们就可以将S称为T的子类型。
为了让读者理解这段话中所体现的设计理念，也就是里氏替换原则（LSP），我们可以来看几个例子。
继承的使用指导
=======
假设我们有一个License类，其结构如下图所示。该类中有一个名为calcFee（）的方法，该方法将由Billing应用程序来调用。而License类有两个“子类型”:PersonalLicense与BusinessLicense，这两个类会用不同的算法来计算授权费用。
上述设计是符合LSP原则的，因为Billing应用程序的行为并不依赖于其使用的任何一个衍生类。也就是说，这两个衍生类的对象都是可以用来替换License类对象的。
反例：正方形/长方形问题
============
正方形/长方形问题是一个著名（或者说臭名远扬）的违反LSP的设计案例
在这个案例中，Square类并不是Rectangle类的子类型，因为Rectangle类的高和宽可以分别修改，而Square类的高和宽则必须一同修改。由于User类始终认为自己在操作Rectangle类，因此会带来一些混淆。例如在下面的代码中：
Rectangle r = …
r.setW（5）；
r.setH（2）；
assert（r.area（）== 10）；
很显然，如果上述代码在…除返回的是Square类，则最后的这个assert是不会成立的。
如果想要防范这种违反LSP的行为，唯一的办法就是在User类中增加用于区分Rectangle和Square的检测逻辑（例如增加if语句）。但这样一来，User类的行为又将依赖于它所使用的类，这两个类就不能互相替换了。
LSP与软件架构
========
在面向对象这场编程革命兴起的早期，我们的普遍认知正如上文所说，认为LSP只不过是指导如何使用继承关系的一种方法，然而随着时间的推移，LSP逐渐演变成了一种更广泛的、指导接口与其实现方式的设计原则。
这里提到的接口可以有多种形式——可以是Java风格的接口，具有多个实现类；也可以像Ruby一样，几个类共用一样的方法签名，甚至可以是几个服务响应同一个REST接口。
LSP适用于上述所有的应用场景，因为这些场景中的用户都依赖于一种接口，并且都期待实现该接口的类之间能具有可替换性。
想要从软件架构的角度来理解LSP的意义，最好的办法还是来看几个反面案例
违反LSP的案例
========
假设我们现在正在构建一个提供出租车调度服务的系统。在该系统中，用户可以通过访问我们的网站，从多个出租车公司内寻找最适合自己的出租车。当用户选定车子时，该系统会通过调用restful服务接口来调度这辆车。
接下来，我们再假设该restful调度服务接口的URI被存储在司机数据库中。一旦该系统选中了最合适的出租车司机，它就会从司机数据库的记录中读取相应的URI信息，并通过调用这个URI来调度汽车。
也就是说，如果司机Bob的记录中包含如下调度URI：
purplecab.com/driver/Bob
那么，我们的系统就会将调度信息附加在这个URI上，并发送这样一个PUT请求：
purplecab.com/driver/Bob
/pickupAddress/24 Maple St.
/pickupTime/153
/destination/ORD
很显然，这意味着所有参与该调度服务的公司都必须遵守同样的REST接口，它们必须用同样的方式处理pickupAddress、pickupTime和destination字段。
接下来，我们再假设Acme出租车公司现在招聘的程序员由于没有仔细阅读上述接口定义，结果将destination字段缩写成了dest。而Acme又是本地最大的出租车公司，另外，Acme CEO的前妻不巧还是我们CEO的新欢……你懂的！这会对系统的架构造成什么影响呢？
显然，我们需要为系统增加一类特殊用例，以应对Acme司机的调度请求。而这必须要用另外一套规则来构建。
最简单的做法当然是增加一条if语句：
if（driver.getDispatchUri（）.startsWith（“acme.com”））…
然而很明显，任何一个称职的软件架构师都不会允许这样一条语句出现在自己的系统中。因为直接将“acme”这样的字串写入代码会留下各种各样神奇又可怕的错误隐患，甚至会导致安全问题。
例如，Acme也许会变得更加成功，最终收购了Purple出租车公司。然后，它们在保留了各自名字的同时却统一了彼此的计算机系统。在这种情况下，系统中难道还要再增加一条“purple”的特例吗？
软件架构师应该创建一个调度请求创建组件，并让该组件使用一个配置数据库来保存URI组装格式，这样的方式可以保护系统不受外界因素变化的影响。例如其配置信息可以如下：
但这样一来，软件架构师就需要通过增加一个复杂的组件来应对并不完全能实现互相替换的restful服务接口。
LSP可以且应该被应用于软件架构层面，因为一旦违背了可替换性，该系统架构就不得不为此增添大量复杂的应对机制。
ISP：接口隔离原则
==========
在上图所描绘的应用中，有多个用户需要操作OPS类。现在，我们假设这里的User1只需要使用op1,User2只需要使用op2,User3只需要使用op3。
在这种情况下，如果OPS类是用Java编程语言编写的，那么很明显，User1虽然不需要调用op2、op3，但在源代码层次上也与它们形成依赖关系。这种依赖意味着我们对OPS代码中op2所做的任何修改，即使不会影响到User1的功能，也会导致它需要被重新编译和部署。
这个问题可以通过将不同的操作隔离成接口来解决，具体如下图所示。
同样，我们也假设这个例子是用Java这种静态类型语言来实现的，那么现在User1的源代码会依赖于U1Ops和op1，但不会依赖于OPS。这样一来，我们之后对OPS做的修改只要不影响到User1的功能，就不需要重新编译和部署User1了。
ISP与编程语言
========
很明显，上述例子很大程度上也依赖于我们所采用的编程语言。对于Java这样的静态类型语言来说，它们需要程序员显式地import、use或者include其实现功能所需要的源代码。而正是这些语句带来了源代码之间的依赖关系，这也就导致了某些模块需要被重新编译和重新部署。
而对于Ruby和Python这样的动态类型语言来说，源代码中就不存在这样的声明，它们所用对象的类型会在运行时被推演出来，所以也就不存在强制重新编译和重新部署的必要性。这就是动态类型语言要比静态类型语言更灵活、耦合度更松的原因。
当然，如果仅仅就这样说的话，读者可能会误以为ISP只是一个与编程语言的选择紧密相关的设计原则，而非软件架构问题，这就错了。
ISP与软件架构
========
回顾一下ISP最初的成因：在一般情况下，任何层次的软件设计如果依赖于不需要的东西，都会是有害的。从源代码层次来说，这样的依赖关系会导致不必要的重新编译和重新部署，对更高层次的软件架构设计来说，问题也是类似的。
例如，我们假设某位软件架构师在设计系统S时，想要在该系统中引入某个框架F。这时候，假设框架F的作者又将其捆绑在一个特定的数据库D上，那么就形成了S依赖于F，F又依赖于D的关系。
在这种情况下，如果D中包含了F不需要的功能，那么这些功能同样也会是S不需要的。而我们对D中这些功能的修改将会导致F需要被重新部署，后者又会导致S的重新部署。更糟糕的是，D中一个无关功能的错误也可能会导致F和S运行出错。
DIP：依赖反转原则
==========
依赖反转原则（DIP）主要想告诉我们的是，如果想要设计一个灵活的系统，在源代码层次的依赖关系中就应该多引用抽象类型，而非具体实现。
也就是说，在Java这类静态类型的编程语言中，在使用use、import、include这些语句时应该只引用那些包含接口、抽象类或者其他抽象类型声明的源文件，不应该引用任何具体实现。
同样的，在Ruby、Python这类动态类型的编程语言中，我们也不应该在源代码层次上引用包含具体实现的模块。当然，在这类语言中，事实上很难清晰界定某个模块是否属于“具体实现”。
显而易见，把这条设计原则当成金科玉律来加以严格执行是不现实的，因为软件系统在实际构造中不可避免地需要依赖到一些具体实现。例如，Java中的String类就是这样一个具体实现，我们将其强迫转化为抽象类是不现实的，而在源代码层次上也无法避免对java.lang.String的依赖，并且也不应该尝试去避免。
但String类本身是非常稳定的，因为这个类被修改的情况是非常罕见的，而且可修改的内容也受到严格的控制，所以程序员和软件架构师完全不必担心String类上会发生经常性的或意料之外的修改。
同理，在应用DIP时，我们也不必考虑稳定的操作系统或者平台设施，因为这些系统接口很少会有变动。
我们主要应该关注的是软件系统内部那些会经常变动的（volatile）具体实现模块，这些模块是不停开发的，也就会经常出现变更。
稳定的抽象层
======
我们每次修改抽象接口的时候，一定也会去修改对应的具体实现。但反过来，当我们修改具体实现时，却很少需要去修改相应的抽象接口。所以我们可以认为接口比实现更稳定。
的确，优秀的软件设计师和架构师会花费很大精力来设计接口，以减少未来对其进行改动。毕竟争取在不修改接口的情况下为软件增加新的功能是软件设计的基础常识。
也就是说，如果想要在软件架构设计上追求稳定，就必须多使用稳定的抽象接口，少依赖多变的具体实现。下面，我们将该设计原则归结为以下几条具体的编码守则：
应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类。这条守则适用于所有编程语言，无论静态类型语言还是动态类型语言。同时，对象的创建过程也应该受到严格限制，对此，我们通常会选择用抽象工厂（abstract factory）这个设计模式。
不要在具体实现类上创建衍生类。上一条守则虽然也隐含了这层意思，但它还是值得被单独拿出来做一次详细声明。在静态类型的编程语言中，继承关系是所有一切源代码依赖关系中最强的、最难被修改的，所以我们对继承的使用应该格外小心。即使是在稍微便于修改的动态类型语言中，这条守则也应该被认真考虑。
不要覆盖（override）包含具体实现的函数。调用包含具体实现的函数通常就意味着引入了源代码级别的依赖。即使覆盖了这些函数，我们也无法消除这其中的依赖——这些函数继承了那些依赖关系。在这里，控制依赖关系的唯一办法，就是创建一个抽象函数，然后再为该函数提供多种具体实现。
应避免在代码中写入与任何具体实现相关的名字，或者是其他容易变动的事物的名字。这基本上是DIP原则的另外一个表达方式。
工厂模式
====
如果想要遵守上述编码守则，我们就必须要对那些易变对象的创建过程做一些特殊处理，这样的谨慎是很有必要的，因为基本在所有的编程语言中，创建对象的操作都免不了需要在源代码层次上依赖对象的具体实现。
在大部分面向对象编程语言中，人们都会选择用抽象工厂模式来解决这个源代码依赖的问题。
下面，我们通过下图来描述一下该设计模式的结构。如你所见，Application类是通过Service接口来使用ConcreteImpl类的。然而，Application类还是必须要构造ConcreteImpl类实例。于是，为了避免在源代码层次上引入对ConcreteImpl 类具体实现的依赖，我们现在让 Application 类去调用ServiceFactory接口的makeSvc方法。这个方法就由ServiceFactoryImpl类来具体提供，它是ServiceFactory的一个衍生类。该方法的具体实现就是初始化一个ConcreteImpl类的实例，并且将其以Service类型返回。
上图中间的那条曲线代表了软件架构中的抽象层与具体实现层的边界。在这里，所有跨越这条边界源代码级别的依赖关系都应该是单向的，即具体实现层依赖抽象层。
一线互联网大厂Java核心面试题库
正逢面试跳槽季，给大家整理了大厂问到的一些面试真题，由于文章长度限制，只给大家展示了部分题目，更多Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等已整理上传，感兴趣的朋友可以看看支持一波！
代表了软件架构中的抽象层与具体实现层的边界。在这里，所有跨越这条边界源代码级别的依赖关系都应该是单向的，即具体实现层依赖抽象层。
一线互联网大厂Java核心面试题库
[外链图片转存中…(img-jSlSzrJn-1715424728464)]
正逢面试跳槽季，给大家整理了大厂问到的一些面试真题，由于文章长度限制，只给大家展示了部分题目，更多Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等已整理上传，感兴趣的朋友可以看看支持一波！
306
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
