設計原則
-
單一職責原則
一個類只承擔一個職責，或者說一個函數的功能要保證單一，不要太複雜，否則進行修改時，會造成其他模塊部件極大影響，取決於該函數被調用的次數，如果該函數在整個系統中頻繁被調用，那麼對於該函數的修改對整個系統是致命的。
-
開放封閉原則
類、模塊、函數可以去擴展，但不要去修改。
修改對於大型程序的影響是致命的，導致的問題是Bug一個接一個，改了東來了西。
如果要修改代碼，儘量用繼承或者組合的方式來擴展類的功能，而不是直接修改類的代碼。
如果能夠保證對整個架構不會產生任何影響，可以直接修改類
-
里氏替換原則
函數內部使用父類的指針或者引用以使得能夠使用子類對象時去調用函數能夠事先不需要知道具體使用的哪一個具體的子類對象。
子類需要重寫調用的方法以達到類使用能夠達到多態的目的。
-
依賴倒置原則
高層模塊不應該依賴於底層，而應該依賴於抽象。抽象不應該依賴於細節，細節應該依賴於抽象。
應該面向接口編程，不應該面向實現類編程。
面向於實現類編程相當於就事論事，屬於正向依賴
面向接口編程，相當於透過現象看本質，抓住事物共性，屬於反向依賴，即依賴倒置。
-
接口隔離原則
不要對外暴露沒有實際意義的接口，外部如果對其調用過多，修改該接口時會造成災難性的後果，所以需要嚴格控制接口的訪問權限。
-
最少知識原則
儘量減少對象之間的交互，從而減小類之間的耦合。做系統設計時，不要讓一個類，依賴太多的其他的類，需儘量減小依賴關係。
遵循以上所有原則主要是爲了程序設計達到“高內聚低耦合”，避免修改BUG到無法改動的結果。
設計模式
以下項目常用設計模式C++實現針對23種設計模式種的常用模式進行了C++代碼的相應實現，原創代碼，代碼處有考慮不周之處歡迎指正。