編程需要注意的陷阱：Java繼承是有害的
發布: 2008-5-07 10:11 | 作者: 不詳 | 來源: 賽迪網技術社區 | 查看: 17次 | 進入軟件測試論壇討論
g2()方法現在能夠遍歷Collection的派生，就像你能夠從Map中得到的鍵值對。事實上，你能夠寫iterator，它產生數據，代替遍歷一個Collection。你能夠寫iterator，它從測試的框架或者文件中得到信息。這會有巨大的靈活性。
耦合
對于實現繼承，一個更加關鍵的問題是耦合---令人煩躁的依賴，就是那種程序的一部分對于另一部分的依賴。全局變量提供經典的例子，證明為什么強耦合會引起麻煩。例如，如果你改變全局變量的類型，那么所有用到這個變量的函數也許都被影響，所以所有這些代碼都要被檢查，變更和重新測試。而且，所有用到這個變量的函數通過這個變量相互耦合。也就是，如果一個變量值在難以使用的時候被改變，一個函數也許就不正確的影響了另一個函數的行為。這個問題顯著的隱藏于多線程的程序。
作為一個設計者，你應該努力最小化耦合關系。你不能一并消除耦合，因為從一個類的對象到另一個類的對象的方法調用是一個松耦合的形式。你不可能有一個程序，它沒有任何的耦合。然而，你能夠通過遵守OO規則，最小化一定的耦合（最重要的是，一個對象的實現應該完全隱藏于使用他的對象）。例如，一個對象的實例變量（不是常量的成員域），應該總是private。我意思是某段時期的，無例外的，不斷的。（你能夠偶爾有效地使用protected方法，但是protected實例變量是可憎的事）同樣的原因你應該不用get/set函數---他們對于是一個域公用只是使人感到過于復雜的方式（盡管返回修飾的對象而不是基本類型值的訪問函數是在某些情況下是由原因的，那種情況下，返回的對象類是一個在設計時的關鍵抽象）。
這里，我不是書生氣。在我自己的工作中，我發現一個直接的相互關系在我OO方法的嚴格之間，快速代碼開發和容易的代碼實現。無論什么時候我違反中心的OO原則，如實現隱藏，我結果重寫那個代碼（一般因為代碼是不可調試的）。我沒有時間重寫代碼，所以我遵循那些規則。我關心的完全實用?我對干凈的原因沒有興趣。