Java设计模式 基本原则（一）

好久没用更新blog了，也是因为升入大二，听说课程会很多，以至于一直没敢安排自己的课余学习。但是毕竟明年的实习就看这个大二上了，周围的人都在做项目或是组团队去干了，自己也不能落下。

这一段时间，也是没做什么项目，看了设计模式的东西。

 

设计模式，简单了解之后，发现这对以后的项目开发真的很有好处，有了好的框架，好的设计，对以后的维护和拓展都会很方便。看了几天之后，还是用blog来记录自己的感悟比较好。

现在先讲讲基本的原则

1.单一职责原则

2.里氏替换原则

3.依赖倒置原则

4.接口隔离原则

5.迪米特法则

6.开闭原则

 

1，单一职责原则

单一职责原则（srp  There should never be more than one reason for a class to change）

单一职责原则，从他的定义就可以看得出来，重点在于 “单一职责”几个字。这个原则就是对接口框架的设计，在实际操作中，需要做到的是接口一点要做到单一职责，而实现类的设计根据实际需要尽量做到只有一个原因引起变化，也就是单一的原则。

看完和简单理解单一职责原则之后，反思一下之前的小项目的代码。虽然都是可以实现功能，但是在操作中遇到的情况就是如果修改一处地方，修改一个功能，就需要改很多的地方，有时候一个细节没用修改，就导致花费很多时间去寻找bug。如果是以后的大项目，这样的设计几乎是致命的。

举个之前的简单例子。在做QQ聊天室的时候，我们定义的一个新的用户的信息，这个类中进行了属性的存储和更改，也进行了用户操作的实现，总之就是几乎所有和一个登陆的用户相关的信息，我们都放在了一个类中。而单一职责原则则要求我们需要把这些东西进行细化，做到一个接口只负责一个职责，多余的不需要干涉（这里的接口并不特指有interface关键字修饰的，而是一个类所具有的方法的特征集合，是一种逻辑上的抽象）。

 

通过对不同职责的细化处理，对之后的维护与拓展有帮助。

 

这里的要点是 我们不是面向类进行编程，而是面向接口进行编程，只要保证一个抽象的接口中是执行一个职责。当然这个职责的划分并不会有一个统一的量化标准，都是需要根据现实的需求去考虑的。我们不应该去为了满足这个原则而去刻意“ 迎合”。

 

似乎讲了许多，之后说了一句不要去刻意迎合原则就把之前的都否定了，因为还是需要视情况而定。其实在学习时，看到一个建议：接口一定要做到单一职责，类的设计尽量的满足单一职责即只有一个原因引起的变化。

 

目前的理解，设计模式是在项目实施之前的一个整体的规划，而不是一上手就一味蛮干，也许有成效，但是提前的设计可以减轻实施时的压力。