最近在讀設計模式之禪
單一職責原則 SPF原則
Single Responsibility Principle
There should never be more than one reason for a class to change
在類設計的時候儘量分清職責,做到業務對象和業務邏輯分離
單一職責原則最難劃分的就是職責,一個職責一個接口,但職責並沒有量化的標準,一個類到底要負責哪些職責?職責如何細化?細化後是否都要有一個接口或類?這些都因項目而異
在類的方法上,也要遵循SPF
一次專注於一件事情已經不是個容易的事情了,不要把問題搞得太複雜
里氏替換原則 LSP原則
Liskov Substitution Principle
Functions that user pointer or reference to base class must be able to use object of derived class without knowing it
只要父類出現的地方,子類都可以出現,而且替換爲子類也不會產生任何錯誤或者異常
- 子類必須完全實現父類的方法
- 子類覆蓋或者實現父類方法時輸入參數可以被放大
..
依賴倒置原則 DIP原則
Dependence Inversion Principle
…
未完,待續
======2016年12月19日更新
介紹一個最近學到概念，叫設計模式與過度設計。
過度設計大體是指軟件迭代過程中需求是不斷的變化的，這意味着對代碼設計的越早，在後期失敗的概率越大，在當時看起來合理的設計，在後期卻會因此花費過多的代價。
對於瞭解設計模式的人來說，設計模式是一種溝通語言，它需要大量的編程經驗，纔可以讓我們實現：重構到設計模式。對於我這樣的新手而言，只需大致瞭解一點就可以了。離開實踐經驗，妄談設計模式，沒太多的益處。所以這個坑先挖着。