设计模式——六大原则

三二一_O

于 2014-11-30 23:54:33 发布

阅读量1k

点赞数

本文链接：https://blog.csdn.net/shamingai/article/details/41211159

版权

看完《大话设计模式》我捧着《head first 设计模式》留下了激动的泪水——637页。

没怎么使用过设计模式，纸上谈一下兵。

我们面向过程的时候（学习VB期间）是不考虑设计模式的，也没有这些概念。当我查阅设计模式资料的时候，好多很牛很厉害的人却很嫌弃面向对象的概念、嫌弃设计模式。一直百思不得其解。所以，要想了解为啥嫌弃它们，首先要知道面向对象学的是什么？设计模式学的是什么？

提到面向对象，就一定会想到【可维护、可复用、可扩展、灵活性好】这四个特性，窃以为在设计模式中体现这些的就是它的六个原则了。

面向对象编程呢，首先你得建个类吧。好，现在问题来了，如何让你的类与众不同，时尚时尚最时尚！

1、单一职责原则

【就一个类而言，应该仅有一个引起它变化的原因。】

这是保证代码健壮性的一条重要原则。

【如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。】

无论创建型还是行为型都有好多模式使用的时候要着重考虑单一职责，比如说观察者模式（Observer）、代理模式（Proxy）、命令模式（Command）、解释器模式（interpreter）等等。我觉得他们相似，大概就是因为类的分离，是使它们更符合单一职责原则的。有趣的是中介者模式（Mediator），它是用中介对象封装对象交互的，各对象之间是不需要显式地相互引用的。虽然解耦合了，相对于上面这些一对一或一对多的关系，中介者明显是多对多的关系。虽然解耦，但它明显是不够符合单一职责原则的，它的每一个中介者都是非常复杂的，所以我们应用中介者的时候首先要要思考的我们的框架是不是不够完善等问题了。

类的职责单一，更改、添加其他功能的时候该对的地方就会很少。非常利于维护、扩展，灵活性也会很好。

2、开闭

【是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。】

说道开闭原则，主要针对OO的可扩展特性，就想对比一下外观模式（Facade）和代理模式（Proxy），它们非常相似，都属于创建型，且都是对上提供了一个接口的机制。不同的是外观看不到内部，而代理能看到。所以做修改的时候外观只需要内部增加内容（扩展开放），就不用再修饰界面了（修改关闭）。但从开闭原则考虑，外观要优一些。命令模式（Command）、原型模式（Prototype）在修改维护时都体现了开闭原则。

数据是无价的，即使是不用的旧代码对程序的完善维护都有很大作用，因此添加但不修改也变得十分必要。开闭原则是在可扩展上的一个细化。

3、依赖倒转

【A：高层模块不应该依赖底层模块。两个都应该依赖抽象。

B：抽象不应该依赖细节，细节应该依赖抽象。】

依赖倒转，其实这种思想非常好理解且非常实用。我们做程序是为了给别人用吧，怎么样的程序才能保证拿来即用呢？那就先看看我们对外接口是怎么设计的了。

和中医的对症下药是一个道理的，医生开药不会因为病人的不同而不同，却会因为病症的相同而相同。医生治病、病人看病，都针对的是这个病症，而非实体的对方。

如果应用在方形的接口，而我们写成了圆形的，那程序还怎么用？同样的如果都是应对方形接口的设计，硬件厂家也不会生产三角形的接口。双方都遵从一些即成的标准，而不是针对对方的实体。

依赖倒转原则中的【抽象】就类似于“病症”和“标准”。这其实是一种分层的思想，这里的【抽象】规定一个标准，交互双方都针对这个标准构建。

修改和添加内容时候才会动的地方少。有了这样的抽象，才能保证灵活。

4、里氏代换

【子类型必须能够替换掉它们的父类型】

如果同一个类会使用很多次，我们会复制粘贴使用吗？当然不是，这样修改起来麻烦极了！我们会考虑【复用】这一技术，把相似子类抽象出一个父类，再用的时候，我们只需要调用即可。里氏代换就是描述的复用。