1. 簡單的設計永遠比複雜的好，原子性的操作要勝於某些貌似更加自動化的機制。
2. 我們真的很在乎一些細緻末節的效率麼？尤其是在假意效率之名破壞簡單清晰的設計時請仔細斟酌是否值得。
3. 比起c++過載某些+-*/之類的方法，我寧願去寫add, mul, div這樣的函式，至少可以讓使用者（或者自己）一目了然的知道這背後意味著什麼樣的運算。
3. 最好不耦合，單向耦合要好於雙向耦合。
4. 在做好第一版之後，再想想是否還可以再簡單一些，而不是盲目的增加貌似有用的功能。
5. 在使用中如果發現對於使用者不夠方便，或者對於日後的擴充套件需要增加很多額外的**，那麼請考慮這樣的設計是否合理，是否足夠簡單。
6. 任何設計都有改進的餘地，做的越深入就越覺得自己的無知，這時請聽聽其他人的想法，或許會有更大的啟發。
幾個設計原則
如果乙個類承擔的 職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭 受到意想不到的破壞。軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。如果你能夠想到多於乙個的動機去改變乙個類，那麼這個類就...
幾個設計原則
如果乙個類承擔的 職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭 受到意想不到的破壞。軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。如果你能夠想到多於乙個的動機去改變乙個類，那麼這個類就...
幾個基本的設計原則
物件導向的分析設計有很多原則，這些原則從思想層面上給我們指出分析設計的正確方向。而設計模式就是這些設計原則的一些具體體現，它是針對某個場景下某些問題的某個解決方案。乙個類應該僅有乙個引起它變化的原因 即它只有乙個職責 開閉原則 軟體實體應當對擴充套件開放，對修改關閉。黎克特制代換原則 任何基類可以出...