如何生动形象的理解七大设计原则

0. 设计模式的目的，什么是好的程序

好的程序要求：

1. 可靠性：当增加了新的功能，对原有的功能没有影响。让你给一个只能加减乘除的计算器，增加平方的功能，你不能图省事把人家的乘法函数改了改，结果基本的加减乘除都用不了了。
2. 高内聚，低耦合：模块内部紧密，模块外部依赖性低。高内聚就是说，餐厅吃饭、摘韭菜、喂宝宝，厕所解手、洗脚、染头发，同类的功能尽量放在一个地方做，这样也好打扫也好找，不要东拉西扯一锅乱粥。低耦合就是说，不要把电视空调洗衣机，每个电器都拉一个线连到户外电网，你家里只要一根总线连到户外电网。
3. 代码重用性高：相同功能的代码不用重复写好多遍。下雨天遇到歹徒，不用去找武器，直接拿伞戳他。碰到小孩落水，顺手拿伞勾上来，一口气上八楼，伞还可以当拐杖使，还可以荡秋千，马桶搋，所以要买个好伞，重用性高的代码要写的结实点。
4. 可读性好：编码规范性。函数和变量的名字要反应出他的用途，遵循clean code。
5. 可扩展性高：要经常考虑以后会出现的需求，容易发胖就把衣服买大一号，不想一直单身最好租个大房子，插线板多留几个孔。

要写出好的程序，就要在编程过程中按照一定的原则来执行。
七大设计模式原则（单接依里开合迪），就是好的程序应该满则的要求，也是设计模式都遵守的纲要。

0 七大设计原则的核心思想

1. 封装变化，暴露稳定点
2. 面向接口编程，而不是面向实现编程。（先用接口搭建框架）
3. 为了交互对象之间的松耦合设计而努力。

1. 单一职责原则

一个类应该只负责一项职责。如果负责两个个职责A和B，当类中的A功能修改后，B相关的会受到影响。【技多压身过劳死】

• 降低类的复杂度，只负责一个职责。
• 降低修改带来的风险

2. 接口隔离原则

客户端不应该依赖他不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。

凡是用不到的接口就给他拆开。

不满足接口隔离原则，应该用抽象类对不需要的接口进做默认实现，改为以下样子。

abstract class InterfaceClassA{
	void operation_1(){}; // 空实现
	abstract operation_2();
	abstract operation_2();
}

abstract class InterfaceClassB{
	abstract void operation_1();
	operation_2(){}; // 空实现
	abstract operation_2();
}

3. 依赖倒置原则

实际问题

【盖房子和买家具】
盖房子的时候不要为了省材料，买个柜子支起一面墙用，因为房子一旦盖好，不好改动，而柜子随便搬。
房子相对于柜子就是一个高层次的东西。柜子要随着房子的大小而挑选，盖房子不能因为买了个巨大的柜子就改变房间的高度。

要求

• 高层模块不应该依赖低层模块，二者都应该依赖其抽象（接口）
• 抽象不应该依赖细节。

核心思想

依赖倒置原则的中心思想是：面向接口编程。

由于细节是经常变化的，而接口相对而言变化较小。所以以接口搭建起来的应用就非常稳定。

使用接口和抽象类的目的在于 ：制定好规范

4. 替换原则（里氏）

程序里面的父子类和生活中的父子关系基本不想关，我们很容易受到这个名字误导对继承的理解。
程序里的继承是一种范围的继承，比如：

• 鸟类与 麻雀、黄鹂、白鹭是父子继承关系，
• 金属与金银铜铁铝是父子继承关系，
• 家畜与猪牛马是父子继承关系，而大猪与小猪不是父子继承关系（亲生的也不是）。

所以说，程序里父类的属性，应该是子类的共有属性，所以子类一般不可以重写父类的方法。

金属具有导电性，他的子类铁也具有导电性，如果“铁”重写了父类“金属”的属性，说我没有导电性，金属说：“你不配做我的子类”。

理解了程序的继承关系，就很好理解里氏替换原则，即任何一个子类都应该能够完全顶替他的父类的属性，比如说，这里需要一根金属做导体。金银铜铁，都应该能够顶替上，而不是说，铁的属性改了，铁不能上。
继承的含义：凡是父类中实现好的方法，都是一种设定的规范和契约，如果子类重写就会破坏这层契约。
替换原则要求：在子类中尽量不要重写父类的方法。如果想要类似的功能，可以通过聚合、组合、依赖，来解决问题。
因为用父类做多态时，会以为父类的方法没有被重写，直接调用，结果确实被子类的重写方法运行。导致程序不清晰。

5 开闭原则（open closed principle）

开闭原则简直就是职场厚黑学，领导滔滔不绝的讲了一早上，讲完自信心满满，随口说了句，“各位有没有要补充的呢？”
你蹭的站起来说：“老板，您说的不对，你刚才讲的方法不符合敏捷开发”，老板笑看着你，腮帮子听见了咬牙根声音。
老板话说的很明白，有没有要补充的，让你扩展扩展，不是让你纠正修改。
一个软件一旦发布，就会牵扯到各方面的关联，不能想改就改，别人今天用着还好好的，你晚上一改，明天全网崩溃。

要求：

• 一个类或者模块，设计的时候要具备对今后做扩展功能保持开放，但对修改坚决关闭。
• 用抽象构建框架，用实现创建细节。当软件需求发生变化时，尽量用扩展的方式满足变化，而不是修改当前的代码。（因为你修改的这段代码可能是别人正在使用的）

6 最少知道原则(迪米特原则）

联想的售后比较好，你的电脑坏了，你最好直接使用：

LianXiang.ShouHou(myComputer);

而不能去找人家联想内部售后部门的张全蛋去给你修，比如以下这样

LianXiang.ShouHouBuMen().7号流水线().ZhangQuandan().Repair(myComputer); // 张全蛋可能都被开除了，你应该让联想内部给你分配人

要求：

• 一个对象应该对其他对象保持最少的了解。
• 类与类之间的关系越密切，耦合度就会越大。
• 只与直接朋友通信。直接是指 A类中有B类作为成员变量、方法参数、方法返回值，就是直接朋友。出现在局部变量的类就是陌生朋友。

如果出现了陌生朋友，就尽量在直接朋友中调用这个陌生朋友，让他们俩成为直接朋友。

7. 合成复用原则

如果想要用某一个功能，比如你想结婚借个气派的宝马，最好的方法是去租一次用用，其次呢是自己买一个，最次的方法是去给宝马车主当个儿子，这样你就继承了这辆车。（不太恰当哈哈）
因为，租一次，你的代价是最小的，买一个就必须画很多钱了，去继承它，就欺师灭祖了。

类的设计也是，不要为了给类增加一个别的类的方法就去继承它，可以保有那个类作为局部变量，或者引用

合成复用原则要求：

• 尽量使用合成、聚合的方式，而不是继承的方式来实现。