单一职责原则

      今天看完单一职责原则后，收获不少，简单的说一下吧。单一职责原则强调的是职责的分离，在某种程度上对职责的理解，构成了不同类之间耦合关系的设计关键，因此单一职责原则或多或少成为设计过程中一个必须考虑的基础性原则。

      关于单一职责原则，其核心的思想是：一个类最好只做一件事，只有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起了，一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，但发生变化时，设计会遭受到意想不到破坏。而如果想要避免这中现象的发生，就要尽可能的遵守单一职责原则。单一职责原则的核心就是解耦合和增强内聚性。

      之所以会出现单一职责原则就是因为在软件设计时会出现同下类似的场景：假设类A负责两个不同的职责，职责B1和职责B2，当由于职责B1需求发生改变而需要修改类A时，有可能会导致原本运行正常的职责B2功能发生故障，也就是说职责B1和B2被耦合在了一起。再举个例子：在MFC中我们常常会在主窗口的类中编写代码来实现我们所需要的功能，自然的也就把相应的代码写入了该窗口类中，即界面跟功能的结合，但如果突然也需要用QT也去做同一功能的界面，原来在MFC中的类的代码就不能直接使用，因为界面和功能代码耦合在一起，需要重新对代码进行修改编写，若是复杂的功能可能就需要花费较长的时间和精力，其实当用QT来实现时只需要修改界面的代码，实现功能的代码不需要去改动，所以这个时候就需要我们运用单一职责原则来解决问题，将界面代码和功能代码放在两个类中，当需要用别的方式来做界面时，实现功能的代码便可直接使用。

      其实没有任何程序设计人员不清楚应该写出高内聚低耦合的程序，但是很多耦合常常发生在不经意之间，让我们难以察觉，原因就是职责扩散：因为某种原因，某一职责被分化为颗粒度更细的多个原则了。所以需要我们遵守单一职责原则，将不同的职责封装到不同的类或模块中。