几种模式

单一职责原则 (Single responsibility Principle)

1.它规定一个类应该只有一个发生变化的原因。所谓职责就是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多余一个的职责。而单一职责的原则就是指一个类或者模块应该有且只有一个改变的原因。

 每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就会耦合在一起了，这会导致脆弱的设计。当一个职责发生变化时，可能会影响其他的的职责。另外，多个职责耦合在一起，会影响复用性。例如，要事先逻辑和界面的分离。

问题由来

之所以会出现单一职责原则就是因为在软件设计时会出现以下类似场景：

T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。也就是说职责P1和P2被耦合在了一起。

产生原因

没有任何的程序设计人员不清楚应该写出高内聚低耦合的程序，但是很多耦合常常发生在不经意之间，其原因就是：

职责扩散：因为某种原因，某一职责被分化为颗粒度更细的多个职责了。

解决办法

遵守单一职责原则，将不同的职责封装到不同的类或模块中。

 

相关知识编辑

单一职责原则并不是一个孤立的面向对象设计原则，它是面向对象设计五个基本原则（SOLID）之一。这些原则是：单一职责原则、开闭原则、接口隔离原则、里氏替换原则和依赖倒置原则。这些原则被一起应用时可以使一个软件系统更易被维护和扩展。这些原则被典型的应用在测试驱动开发上，并且是敏捷开发以及自适应软件开发等指导思想的重要组成部分。

 

依赖倒置原则（Dependence Inversion Principle）

 

A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象

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

 

即：程序要依赖于抽象接口，不要依赖于具体实现。简单地说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

 

面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。

面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。