单一职责原则，顾名思义，就是一个类只有一个职责。那么这个职责到底是什么意思呢？它可以被理解为“引起变化的原因”。如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。
什么叫“引起变化的原因”？举个例子：有三只猫：白猫、黑猫、花猫。如果以编程的角度来看，是不是就要有三个类，白猫类，黑猫类，花猫类呢？当然不是！这里不同的只是猫的颜色，并且这个颜色还会拓展，以后可能有蓝猫；那么在这里，颜色就是引起变化的原因。设计时，将颜色视为一个抽象角度，对其进行抽象。
引起变化的原因： 对象中，变化（不同）的部分，和以后有可能会拓展的部分。
然而，在现实的设计中，很难做到所有的类都实现单一职责原则。所以一般这样规定：接口一定要实现单一职责原则；类尽量做到单一职责。
结合抽象来看，每一个职责对应的应该就是一个独立的、最小粒度的抽象角度。
举个例子：对苹果、香蕉、葡萄、橘子抽象。
分析：虽然他们都是水果，但还是有不同点的。首先，他们的外观不同，那么这个外观就是一个“引起变化的原因”，即职责；那么我们就要对应的的抽象出一个外观接口。然后，味道也不同；那么味道就是它的第二个职责。成分也不同，那么成分就是第三个职责。以此类推，找出所有的职责，然后将这些职责“组合”在一起，就成了水果类了。
到这里基本已经实现了单一职责了，虽然Fruit并非单一职责，但毕竟是面向接口编程，只有接口对外可见。若想将Fruit也分解，可以采用下面的方案：
原文链接：https://www.f2er.com/javaschema/285717.html
