教为学：设计模式学习之路（一）：设计模式的基本设计原则

教为学：设计模式学习之路（一）：设计模式的基本设计原则

前言

概念性的东西让人头痛，又不得不说。

好像设计模式也很大程度上也偏向概念，甚至在一般的做增删改查程序员中，这些东西不是特别重要。

但是如果需要阅读框架源代码，对设计模式的了解和熟悉又必不可少，以前听Jfinal的作者也常常抱怨java的开源框架有很多存在过度设计，个人想了解设计模式是想开启自己阅读开源框架源码打好一条路子。

我们对原则进行简单的描述，能不能完全理解并不重要，很多东西是没有办法在短时间内凭借别人的一点点描叙一下子弄懂的。

但是我们起码得有点点概念。

单一职责原则

定义

我在网上找到了两种定义：

1. 一个类仅有一个导致它变化的原因。
2. 一个对象只包含单一职责，并且该职责被完整的封装在一个类里面。

我的理解

第一个好像是其标准定义，个人感觉难以理解，第二个好像容易理解一些。就是我们常常说的高内聚，低耦合。

而整个定义最让人无法理清的是职责本身？

职责本身太抽象，以至于，我们该怎么界定职责本身。什么叫单一职责。职责的颗粒度是最大的问题。

开发-关闭原则

定义

一句话：

对扩展开放，对修改关闭。

我的理解

对于这一点的实现在于分离变化与不变化的部分，抽象在这里面起了很重要的作用，然后把可变化的因素封装起来。

里式替换原则

定义

在软件系统中一个可以接受基类的地方，肯定可以接受子类。

我的理解

其实就是这个原则就是最好实现开闭原则的方式之一。基类是本身的功能，关闭的部分，子类是扩展的部分，同时保证了基类不需要修改。

依赖倒置原则

定义

高层模块不依赖底层模块，两者都依赖接口。

抽象不应该依赖具体实现，具体实现应该依赖于抽象。

我的理解

其实有点java经验的，我们都明白这东西，我们太熟了。依赖注入控制反转，同样是解耦合的。

接口隔离法则

定义

客户端不应该依赖哪些不需要的接口

我的理解

某种意义上是单一职责原则的另外表达，不应该依赖于哪些大而全的接口，而是依赖于那些专而精的接口。

最小知识原则

定义

不要和陌生人说话。

我的理解

不和陌生人说话，意思就是我们只和朋友说话，所谓朋友就是所必须依赖的类。

结束

其实，就是我的读书笔记的总结。

可以看看研磨设计模式这本书。以及下面这篇博文。

设计模式原理与详解。

http://blog.csdn.net/hguisu/article/details/7571617