- 什麼是原則
原則是一種規則、信仰或者指引你的觀念，原則通常與價值觀或價值體系直接聯繫。 - 保持簡單直接原則（KISs）
KISS是（Keep is simple, stupid或 Keep it simple and stupid）
任何事情都應該儘可能簡單，而不是稍微簡單一點
–Albert Einstein, theoretical physicist, 1879-1955
對程序員來說，關注簡單性可能是最困難的事情之一，並且這是一個終生的學習經驗。
–Adrian Bolboaca(@adibolb),April 3, 2014, on Twitter - 不需要原則（YAGNI）
總是在你真正需要的時候再實現它們，而不是在你只是遇見到你需要它們的時候實現它們。
– Ron Jeffries, You’re NOT gonna need it !
它的主旨是希望你不要寫目前用不上，但將來也許需要的代碼。 - 避免複製原則（DRY）
複製和粘貼是一個設計錯誤。
– David L.Parnas - 信息隱藏原則
該原則指出，一段代碼調用了另外一段代碼，那麼，調用者不應該知道被調用者的內部實現。否則，調用者就有可能通過修改被調用者的內部實現而完成某個功能，而不是強制性地要求調用者修改自己的代碼。
信息隱藏的優點：
1). 限制了模塊變更的範圍
2). 如果需要修復缺陷，對其他模塊的影響最小。
3). 顯著提高了模塊的可複用性。
4). 模塊具有更好的可測試性。 - 高內聚原則
軟件開發中的一條通用建議是，任何軟件實體（如模塊、組件、單元、類、函數等）應該具有很高的（或強的）內聚性。一般來講，當模塊實現定義確切的功能時，應該具有高內聚的特性。 - 鬆耦合原則
考慮下面的示例代碼：
class Lamp {
public:
void on(){
//...
}
void off(){
//..
}
};
class Switch {
private:
Lamp& lamp;
bool state{false};
public :
Switch(Lamp &lamp):lamp(lamp){}
void toggle() {
if (state) {
state = false;
lamp.off();
} else {
state = true;
lamp.on();
}
}
};
這個設計有什麼問題？
問題就是，我們的Switch類直接包含了一個具體類Lamp的應用。換句話說，這個Switch類知道那是一個具體的Lamp類。
在軟件開發中，鬆耦合的關鍵是接口。接口聲明類的公共行爲，而不涉及該類的具體實現。接口就像合同，而實現接口的類負責履行契約，也就是說，這些實現接口的類必須爲接口的方法簽名提供具體的實現。
在C++中，使用抽象類實現接口，如下所示：
class Switchable{
public:
virtual void on() = 0;
virtual void off() = 0;
};
這個Switch類不在包含Lamp類的引用。相反，它持有了我們新定義的Switchable接口類。
class Switch{
private:
Switchable& switchable;
bool state{false};
public:
Switch(Switchable& switchable): switchable(switchable){}
void toggle() {
if ( state) {
state = false;
switchable.off();
} else {
state = true;
switchable.on();
}
}
};
這個Lamp類實現了我們新定義的Switchable接口。
class Lamp : public Switchable{
public:
void on(0 override{
//...
}
void off() override{
//...
}
};
鬆耦合可以爲系統的各個獨立的模塊提供高度的自治性，該原理可以適用於很多不同層次：可以用在最小的模塊上，當然，還可以用在大型組件的體系結構上。高內聚會促進鬆耦合，因爲具有明確定義責任的模塊，通常會依賴於較少的其他模塊。
- 小心優化原則
不成熟的優化是編程中所有問題（或至少是大部分問題）的根源。
–Donald E. Knuth,American computer scientist[Knuth74]
建議：只要沒有明確的性能要求，就避免優化。
note： profiler是一種動態程序分析工具。除其他常用指標外，它還測量函數調用的頻率和持續時間，它收集的分析信息還可用於程序優化。 - 最少驚訝原則（PLA）
最少驚訝原則（POLA、PLA），也稱爲最少驚喜原則（POLS），它在用戶界面設計和人因工程設計中很知名。該原則指出不應該讓用戶對用戶界面的意外響應而感到驚訝，也不應該對出現或消失的控件、混亂的錯誤信息、公認的按鍵序列的異常響應或其他意外行爲而感到困惑。
這個原則也可以很好地應用到軟件開發中的API設計中。調用函數不應該讓調用者感知到異常行爲或一些隱藏的副作用，函數應該完全按照函數名稱所暗示的意義執行。 - 童子軍原則
這個原則是關於你和你的行爲的，其內容是：在離開露營地的時候，應讓露營地比你來之前還要乾淨。
童子軍非常有原則，其中一個原則是，一旦他們發現了一寫不好的東西，就立即清理環境中的污染物或那些引起混亂的東西。作爲一名負責任的軟件工程師，我們應該將這一原則應用於我們的日常工作，每當我們在一段代碼中發現需要改進的或者風格不好的代碼時，我們應該立即修正它，與這段代碼的原創是誰無關緊要。