标签：开发人员 alt 数据库 .com 过程 原则 就会 第三方 用户
第10章 Liskov 替换原则（LSP）
原则解释：
子类型（sbutype）必须能够替换掉它们的基类型（base type）
这一章没大看懂，貌似和 OCP（开发关闭原则）关系很大，以后再研究
第11章 依赖倒置原则（DIP）
原则解释：
a. 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。
b. 抽象不应该依赖于细节。细节应该依赖于抽象。
“请注意这个规则里的倒置不仅仅是依赖关系的倒置，它也是接口所有权的倒置。我们通常会认为工具库应该拥有它们自己的接口。但是当应用了 DIP 时，我们发现往往是客户拥有抽象接口，而它们的服务者则从这些抽象接口派生。”
这里谈下我自己对这段话的理解：
由于在平常的开发中，我接触到的以及我自己使用的方式都是，将接口和对应实体类的名字起的相似（后者在前者的名字后加上 impl），所以自然而然地就会认为它们俩是一体的，即“工具库拥有它们自己的接口”
而仔细想一下的话，会发现，其实被调用方存在的意义是：调用方有相关的需求，即调用方需要一些东西，然后说明了自己需要什么样的东西（制定规则），然后被调用方才按照这些规则去做相关的实现。（可以参考实际工作中：正是因为有了需求，技术才有存在的意义）
即，规则的拥有者和制定者从来都是调用方，而不是被调用方
这里可以联想一下 JDBC 相关知识，我们知道，JDBC 自己制定了规范，然后使用 JDBC 操作数据库的用户就可以不必理会数据库具体的实现细节了，他们只需要调用 JDBC 规定好的那些接口就行了（屏蔽了实现细节）
而在 Java 和 数据库厂商 之间，谁拥有主动权？
是 Java
由于 Java 良好的特性，Java 的市场非常的广泛，并且在未来的使用规模也非常可期
由于这一点，和 Java 合作的话，会获取到非常大的市场空间
所以，从商业角度来说，数据库厂商看到这一趋势之后，必定会迎合 Java 的规范
这时，拥有了话语权的 Java（可以看做甲方） 必定会站在自己的角度，制定一套规范，让使用 Java 的开发人员只需要面对这个规范操作数据库（因为在无需关注数据库相关实现细节的情况下，开发人员会省去很多精力，这样一来，Java 受到更多的开发人员欢迎）
在这个例子中，Java 可以被认为是调用方，数据库可以被认为是被调用方，JDBC 规范可以被认为是抽象接口
很显然，JDBC 不是数据库对外暴露的接口规范，而是 Java 作为调用方站在自己的角度，制定的一套规范
理解了接口所有权的归属问题之后，就能理解这个原则的名字为什么叫“依赖倒置”了
画图说明
一般的面向过程编程中，高层对低层的依赖关系如下：
A 所在模块被称为高层模块，B 所在模块被称为低层模块，则在此关系中，高层模块直接依赖于低层模块
当使用接口作为中间人时，如果这么理解
认为接口（b）所有权归被调用方（B）所有
则依赖关系如下图：
即，还是 A 所在的高层模块在依赖 B 所在的低层模块，并没有发生所谓的依赖“倒置”
但是，但我们换一个理解方式，即
认为接口（b）所有权归调用方（A）所有
则依赖关系如下图：
显然，这样理解的话，可以很明显的看出，依赖关系被“倒置”了，因为在此图中，A 所在的模块被 B 所在的模块所依赖
更高阶的操作（或者说更高阶的理解）
即，接口没有所有者，它自己独立于被调用方和调用方，成为了第三个模块
具体可见可见书中 11.3 小节最后几段的叙述
回到上述我画的几个图中，由于 b 和 B 的关系互为大小写，所以会对这种理解造成阻碍，所以，把 b 换成另外一个名字，再重新画一张依赖图：
是否可以按照这个思路理解 Spring 的 IOC 容器呢？即，按照那个流传的说法：调用方和被调用方解耦，它们都依赖于第三方容器
看完这一章的内容，才大概明白一直被吹捧的 Spring 牛在哪里，以及为什么 IOC 是 Spring 的核心之一
同时，结合 Spring，也能更理解书中的一些描述：
“如果高层模块独立于底层模块，那么高层模块就可以非常容易地被重用。该原则（指依赖倒置原则）是框架设计的核心原则”
“使用传统的过程化的程序设计所创建出来的依赖关系结构，策略是依赖于细节的。这是糟糕的，因为这样会使策略收到细节改变的影响。面向对象的程序设计倒置了依赖关系结构，使得细节和策略都依赖于抽象，并且常常是客户拥有服务接口”
“事实上，这种依赖关系的倒置正是好的面向对象设计的标志所在。使用何种语言来编写程序是无关紧要的。如果程序的依赖关系是倒置的，它就是面向对象的设计。如果程序的依赖关系不是倒置的，它就是过程化的设计”
“依赖倒置原则是实现许多面向对象技术所宣称的好处的基本低层机制。它的正确应用对于创建可重用的框架来说是必须的。同时它对于构建在变化面前富有弹性的代码也是非常重要的。由于抽象和细节被彼此隔离，所以代码也非常容易维护。”
个人感悟：
关于经典的原则和设计思想，如果想要深入理解的话，最好直接找到对应的经典书籍查看，而不是在网上找一堆博客看，一来很多博主自己都没有理解清楚，二来，就算博主理解清楚了，也不一定有与那些能写出经典书籍的大师相当的表达能力
如果哪位朋友碰巧看了本文，那么推荐你看看《敏捷软件开发 原则、模式与实践》这本书，书名讲的是敏捷开发，其实里面的内容是面向对象设计的原则和模式，认真看了本书，可以带你进入 OOP 的大门（套用刘大的话，哈哈）。
第12章 接口隔离原则（ISP）
原则解释：
不应该强迫客户依赖于它们不使用的方法
只看了一小部分，大概的理解是：
接口或类中的所有方法，如果可以被更进一步地分组，则应该将它们放置于不同的类或接口中，而不应该笼统地放到同一个类或接口中
标签：开发人员 alt 数据库 .com 过程 原则 就会 第三方 用户
原文地址：https://www.cnblogs.com/stone94/p/10591472.html
