（2）單一職責原則和（3）開放-封閉原則

單一職責原則SRP：SingleResponsibility Principle，就一個類而言，應該僅有一個引起它變化的原因。

        如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的功能。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。正如一個人可能擔負著很多重要的職責，那麼對他而言合理分配時間去做各項任務就變得尤為重要。若有兩種以上的事情在某一時間內由一個人去解決，那麼他做任何一件事都會影響做另一件事的效果。所以必須GTD。

        軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。其實要去判斷是否應該分離出類來，就是如果你能夠想到多於一個的動機去改變一個類，那麼這個類就具有多於一個的職責。當然GTD並不是要分離出多個自我來，而是分配多個時間段，在每個時間段內只有一個我。這樣就實現了一個類一個職責的效果。

        在編程時，我們要在累的職責分離上多思考，做到單一原則，這樣代碼才真正易維護、易擴充、易複用、靈活多樣。

開放-封閉原則OCP：theOpen-Closed
Principle 

    在軟體設計模式中，不能修改但可以擴充的思想是最重要的一種設計原則，即開放-封閉原則：軟體實體（類、模組、函數等等）應該可以擴充，但是不可修改。為了面對需求的改變仍可以保持相對穩定，從而使得系統在第一個版本以後不斷推出新的版本，就要對擴充開放而對更改封閉。在計算機的例子中，我們通過增加一個抽象的運算類，通過一些物件導向的手段如繼承、多態等來隔離具體演算法與client的耦合，如果要增加其他運算比如開根，不需要更改已有具體演算法類和client，而是增加子類即可。所以，面對程式的改動是通過增加新代碼進行的，而不是更改現有的代碼，這就是開放-封閉原則的精神所在。所以，無論模組是多麼的封閉，都會存在一些無法對之封閉的變化。既然不能完全封閉，設計人員必須對模組應該對哪種變化封閉做出選擇，猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。但是應該僅對程式中頻繁變化的那些部分做出抽象，也不能對每個部分都刻意進行抽象。