單一職責原則，顧名思義，就是一個類只有一個職責。那麼這個職責到底是什麼意思呢？它可以被理解爲“引起變化的原因”。如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當一個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響複用性。
什麼叫“引起變化的原因”？舉個例子：有三隻貓：白貓、黑貓、花貓。如果以編程的角度來看，是不是就要有三個類，白貓類，黑貓類，花貓類呢？當然不是！這裏不同的只是貓的顏色，並且這個顏色還會拓展，以後可能有藍貓；那麼在這裏，顏色就是引起變化的原因。設計時，將顏色視爲一個抽象角度，對其進行抽象。
引起變化的原因： 對象中，變化（不同）的部分，和以後有可能會拓展的部分。
然而，在現實的設計中，很難做到所有的類都實現單一職責原則。所以一般這樣規定：接口一定要實現單一職責原則；類儘量做到單一職責。
結合抽象來看，每一個職責對應的應該就是一個獨立的、最小粒度的抽象角度。
舉個例子：對蘋果、香蕉、葡萄、橘子抽象。
分析：雖然他們都是水果，但還是有不同點的。首先，他們的外觀不同，那麼這個外觀就是一個“引起變化的原因”，即職責；那麼我們就要對應的的抽象出一個外觀接口。然後，味道也不同；那麼味道就是它的第二個職責。成分也不同，那麼成分就是第三個職責。以此類推，找出所有的職責，然後將這些職責“組合”在一起，就成了水果類了。
到這裏基本已經實現了單一職責了，雖然Fruit並非單一職責，但畢竟是面向接口編程，只有接口對外可見。若想將Fruit也分解，可以採用下面的方案：
