【设计模式开篇】六大设计原则

一、设计模式简介

设计模式是一套被反复使用、多人知晓、分类编目的代码设计经验的总结，可以解决特定场景的问题的一系列方法。

 

二、为什么学习设计模式

对于那些在维护一个老项目的人应该深有体会，有的时候，一个很简单的需求，或者说，本来应该是很快就可以实现的需求，但是由于系统当初设计的时候没有考虑这些需求的变化，或者随着需求的累加，系统越来越臃肿，导致随便修改一处都可能造成不可预料的后果，或者是我本来可以修改下配置文件或者改一处代码就可以解决的事情，结果需要修改N处代码才可以达到我的目的。

       以上都是非常可怕的后果，这些我已经深深体会过了。

 

三、设计模式的好处和注意点

设计模式可以帮助我们改善系统的设计，增强系统的健壮性、拓展性。

但是，过多的模式也会让系统变得复杂，所以在第一次设计一个系统时，请你将确定的变化点处理掉，不确定的变化点千万不要假设它存在，如果你曾这样做过，那么请改变你的思维，让这些虚无的变化点在你脑子中彻底消失。

因为我们完全可以使用另一种手法来容纳我们的变化点，那就是重构，不过这是我们在讨论过设计模式之后的事情，现在我们就是要把这些设计模式全部理解，来锻炼我们的思维。

 

四、指导原则：六大原则

这些原则是指导模式的规则，注意，原则是死的，人是活的，所以并不是要完完全全遵守这些原则，数据库设计也可以逆范式，只是在可能的情况下，尽量遵守。

 

①　单一职责原则：每个类都只负责单一的功能，切不可太多，而且尽可能把一个功能做到极致

②　里式转换原则：这个原则表达的意思是一个子类应该可以替换掉父类而且可以正常工作

③　接口隔离原则：也称为接口最小化原则，强调的是一个接口拥有的行为应该尽可能的小

④　依赖倒置原则：这个原则描述的是高层次模块不应该依赖于低层次的模块，二者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象

⑤　迪米特原则：又叫最少知道原则，一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解，只和朋友通信，不和陌生人说话

⑥　开闭原则：对修改关闭，对拓展开放

 

五、依赖倒置详解

上层模块不应该依赖底层模块，它们都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。

首先，这个原则听起来很像是“针对接口编程，不针对实现编程”，不是吗？的确很相似，然而这里更强调“抽象”。

在依赖倒置原则中的倒置指的是和一般OO设计的思考方式完全相反。

举个例子，现在你需要实现一个比萨店，你第一件想到的事情是什么？我想到的是一个比萨店，里面有很多具体的比萨，如：芝士比萨、素食比萨、海鲜比萨……

比萨店是上层模块，比萨是下层模块，如果把比萨店和它依赖的对象画成一张图，看起来是这样：

 

 

 

没错！先从顶端开始，然后往下到具体类，但是，正如你看到的你不想让比萨店理会这些具体类，要不然比萨店将全都依赖这些具体类。现在“倒置”你的想法……别从上层模块比萨店开始思考，而是从下层模块比萨开始，然后想想看能抽象化些什么。你可能会想到，芝士比萨、素食比萨、海鲜比萨都是比萨，所以它们应该共享一个Pizza接口。对了，你想要抽象化一个Pizza。好，现在回头重新思考如何设计比萨店。

 

 

 

图一的依赖箭头都是从上往下的，图二的箭头出现了从下往上，依赖关系确实“倒置”了

另外，此例子也很好的解释了“上层模块不应该依赖底层模块，它们都应该依赖于抽象。”，在最开始的设计中，高层模块PizzaStroe直接依赖低层模块（各种具体的Pizaa）,调整设计后，高层模块和低层模块都依赖于抽象（Pizza）

 

六、OO设计中的类图