?
目錄
1.設計父類時考慮不周到，等到設計或者編寫子類的時候，才發現父類需要修改、增加功能等等，都很平常
2.盡量避免多次寫同樣的代碼
3. 持續改進
4.評價軟件設計的高低的幾個基本原則
內容
1.軟件設計/編程中，有一門基本技術叫“面向對象編程”。面向對象編程的基本思路是對象封裝和繼承。繼承的基本思路是，所有子類共同的部分，提取、抽象后，放到父類中。
這是一個說起來容易，做起來難的事情。父類總是先設計，先實現。一個父類一般都有多個子類。沒有人能夠先知先覺。設計父類時考慮不周到，等到設計或者編寫子類的時候，才發現父類需要修改、增加功能等等，都很平常。例如
public class RequestInfo{
??? public DataItem getDI(String name){
??? }
}
public class DataItem{
??? public String getValue() {
??? }
}
當我們經常寫
String cycCode = info.getDI("cycCode") == null ? null : info.getDI("cycCode").getValue();
的時候，我們自然會想，如果在 class?RequestInfo 中增加一個函數 getDIValue() 就可以寫更短的代碼了：
String cycCode = info.getDIValue("cycCode");
這樣做的好處，代碼更簡潔，更易懂，也更容易維護。
同樣的道理，當我們經常需要從 info 中取 int value 的時候，我們自然會知道，應該往 class RequestInfo 中增加 getIntValue().
2.在軟件開發的過程中，最基本的原則是，避免多次寫同樣的代碼。舉例來說：
這是很常見的基類設計時考慮不周導致的問題，每個子類有同樣的代碼，。解決方法也很簡單，將共同的部分放在 base class 中就可以了：
?
3.軟件行業和其他行業一樣，要想做出質量好的產品，關鍵在于“持續改進”。持續改進的意思是，如果發現了不好的設計，就應該修改。然而，很多時候事情并不這樣簡單。
例如，一個公司有兩百個同樣的生產線，現在有人發現了一個改進辦法，可以提高效率。我們都知道，不可能把所有的生產線同時進行改造，那樣對于現有的生產造成很大的影響，并且從人力物力方面，也有很大問題。更好的辦法是，對于新的生產線，采用新的改進辦法。原有的生產線，既然還能工作，就不用立即修改，可以在以后逐步改進。
這個例子換成軟件行業的話：
一個公司有兩百個類似功能的軟件模塊/類(比如 xxxBPI)，現在有人發現了一個改進辦法，可以在子類中寫更少的代碼，提高效率，代碼更易于維護。我們都知道，不可能把所有 xxxBPI同時進行改造，那樣對于現有的開發造成很大的影響，并且從人力物力方面，也有很大問題。更好的辦法是，對于新的xxxBPI，采用新的改進辦法。原有的代碼，既然還能工作，就不用立即修改，可以在以后逐步改進。
因此，大型的軟件中，新老方法并用的情況很多。比如， MS SQL Server, 很多原有的代碼是從 Sybase 購買，MS 的技術專家發現了一些提高性能的辦法，在經過多年，多個版本更新后，才逐步完成了改進老的代碼。在開源的項目上面，也有很多項目版本說明中申明，計劃采用某某技術改寫原有的代碼，目前完成哪些模塊，計劃增加哪些模塊。改進和增加新功能永遠是同時進行的。
上面的例子，采用持續改進的方法后，變成下面的樣子：
4.評價軟件設計的高低的幾個基本原則
評價軟件設計的高低的幾個基本原則依次為：易懂，易用，穩定性，功能。
易懂：VB 的用戶之所以比 VC 多，在于它易懂。用 Word 寫設計文檔的人比用 Rose 的人多，也在于懂 Word 的人更多。易懂意味著可以用更短的時間學會。
易用：如果 class A 和 class B 完成同樣的功能，但使用 class A 需要寫的代碼更少，我們就說 class A 設計得比 class B 更好。因為使用 class A 寫代碼，代碼更短，開發效率更高。代碼短對于以后的維護也更容易。
穩定性，功能：軟件的賣點在于穩定性，功能。之所以這兩項排在前面亮項后面，同樣有事實為證：Unix/Linux 的穩定性、功能超過于 Windows，但是它的用戶反而少，原因就在于它輸在 “易懂，易用”這兩項上面。