面向对象的六大设计原则的个人理解及笔记

准备

简单把这六(七)个设计原则分为三类

面向对象的本质	保持单一	其他
开闭原则	单一职责原则	合成复用原则
里氏代换原则	接口隔离原则	迪米特法则
依赖倒转原则

希望以最简单的方式来说明这六个原则

面向对象的本质

一句话总结
开闭原则是目标，里氏代换原则是基础，依赖倒转原则是手段（实现）

所谓开闭

程序做好了随便用（继承），但是不能随便改
反例：python2因为没有想这么多，导致3根本不能用2的方法必须重写
（虽然说我的入门语言时python，但是我真的不是很喜欢）

所谓里氏替换

基类（超类）必须尽可能详细，而不是想靠子类来完善
反例：我做抓包时候经常会遇到一些三流API
响应成功返回{msg:'ok'}，失败时候返回{errMsg:'not ok'}
这种明显就是想一出是一出自己随便编了2个结果类给送出去了，根本没有按照里氏替换原则来创建API
正常情况都会统一写一个BaseAPI来指定结果类的规范

所谓依赖倒转

制作一个中间商（抽象类）赚差价，降低客人和商家的之间耦合
反例：很抱歉这个我真的没遇到过，不过百度百科的例子举得很好
我是这么理解的，拿中间商（抽象类）来说，他可以进行任意东西的贩卖（提供抽象方法）
客人可以需求西瓜和矿泉水，同时还可以定制化（你这瓜包甜不？）
但如果直接去问供应商买（孙红雷或者李彦宏）就很麻烦，因为很多第一方没有贩卖技巧，或者不太愿意为了你再去搞定制化（违反开闭原则），搞得不好还会被反问一句沃次有阿普拉不论

关于为什么会叫依赖倒转
原来的关系是这样的

有需求 →	满足需求
客人→	商家

现在变成：

有需求→	满足需求	← 提供需求
客人（细节）→	中间商（抽象类）	← 商家（细节）

中间商为双方制定了规范方便2者进行交易（通讯）
所以这里也引出依赖倒转的定义：
抽象不应该依赖于细节，细节应当依赖于抽象

保持单一

单一职责和接口隔离感觉差不多
在Java中实现一个接口就必须重写接口内的所有方法，所以如无必要，务增实体
反例：太多了，各种神仙

image.png

另外俩

合成复用

少用继承，多用组合或者关联，而且只要你愿意二者是完全可以替换使用的
继承很好理解子盛父液，所谓组合/关联我的理解就是new了
这里主要从继承的缺点来考虑

1. 继承后父类对子类透明
2. 父类发生更改子类也必须改动

而组合关联则可以没有上述问题，并且可以通过Spring的控制反转来进一步降低耦合
反例：想不到，因为一般我不用继承
我看到有例子去让继承DBUtil然后连接数据库，我的妈，老师没这么教的，我真的不会

迪米特法则

也即最少知识原则，个人比较习惯这个。
（话说宇宙刑警失落的宇宙里面米莉就吐槽我以后挖新矿一定要以自己名字命名让兔崽子记不住...）
一句话概括，不要和陌生人说话
反例：jsp
mvc模式还可以被拆成mvvm，就是因为view层依然关联的太多
另外提一下guava有个eventBus，一开始只觉得他可能像个MQ
实际上通信哪怕是在一个工程内的通讯都可能发生我说的是A你却只认识a的情况，一旦报错没抓住，完蛋

后记

个人觉得学习设计模式是有意义的
在看这六大设计原则时我自己会体会到，随着逐渐提高代码质量，自己会无意识得趋向哪些被定义的设计模式
但面试时候问你懂不懂设计模式或者让你介绍下设计模式
这特么纯属脑残行为
写的一手好代码的不一定会去特地看此类面试题
但是代码写的烂或者面试没信心的绝对会去学（比如我）
没有代码经验的去看设计模式绝对一脸懵逼，只有接触了丰富经验的才会在看到设计原则的时候感叹原来我没走错路
说到底，面试面这个仅仅是面试官自己又懒又菜不肯阅读面试者的代码而已

参考

https://blog.csdn.net/lovelion/article/details/17517213
原书的定义非常棒
但其的例子我觉得非常生硬，我看定义时候就不喜欢看代码
最少知识原则