单一职责原则

单一职责原则

          单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。

          我们在编程的时候，很自然的就会给一个类加各种各样的功能，比如我们写一个窗体应用程序，一般都会生成一个From1这样的类，于是我们就把各种各样的代码，都写到这样的类当中，这就意味着，无论是任何需求的变化，都需要修改这个窗体类，这其实是很糟糕的，维护麻烦，不可能复用，缺乏灵活性。

          优点：

          1、类的复杂性降低，实现什么职责都有清晰明确的定义。

          2、可读性提高，复杂性降低，那当然可读性提高了。

          3、可维护性提高，可读性提高，那当然更容易维护了。

          4、变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性，维护下都有非常大的帮助。

          大多数时候，一件产品简单一些，职责单一一些，或许是更好地选择，这就是设计模式中的一大原则——单一职责原则。

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

          软件设计真正要做到许多内容，就是发现职责并把那些职责相互分离，其实，就是要去判断是否应该分离出类来，如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，这时，就应该考虑类的职责分离。

          职责分离可以把事情做得更好，在编程时，我们需要在类的职责分离上多思考，做到单一职责，这样代码才是真正的易维护，易扩展，易复用，灵活多样。