(1)在現(xiàn)成類的基礎(chǔ)上創(chuàng)建新類時，請首先選擇“新建”或“創(chuàng)作”。只有自己的設(shè)計要求必須繼承時，才應(yīng)考慮這方面的問題。若在本來允許新建的場合使用了繼承，則整個設(shè)計會變得沒有必要地復(fù)雜。

(2)用繼承及方法覆蓋來表示行為間的差異，而用字段表示狀態(tài)間的區(qū)別。一個非常極端的例子是通過對不同類的繼承來表示顏色，這是應(yīng)該避免的：應(yīng)直接使用一個“顏色”字段。

(3)為避免編程時遇到麻煩，請保證在自己類路徑指到的任何地方，每個名字都僅對應(yīng)一個類。否則，編譯器可能先找到同名的另一個類，并報告出錯消息。若懷疑自己碰到了類路徑問題，請試試在類路徑的每一個起點，搜索一下同名的.class文件。

(4)在Java 1.1 AWT中使用事件“適配器”時，特別容易碰到一個陷阱。若覆蓋了某個適配器方法，同時拼寫方法沒有特別講究，后的結(jié)果就是新添加一個方法，而不是覆蓋現(xiàn)成方法。然而，由于這樣做是完全合法的，所以不會從編譯器或運行期系統(tǒng)獲得任何出錯提示——只不過代碼的工作就變得不正常了。

(5)用合理的設(shè)計方案消除“偽功能”。也就是說，假若只需要創(chuàng)建類的一個對象，就不要提前限制自己使用應(yīng)用程序，并加上一條“只生成其中一個”注釋。請考慮將其封裝成一個“獨生子”的形式。若在主程序里有大量散亂的代碼，用于創(chuàng)建自己的對象，請考慮采納一種創(chuàng)造性的方案，將些代碼封裝起來。

(6)警惕“分析癱瘓”。請記住，無論如何都要提前了解整個項目的狀況，再去考察其中的細節(jié)。由于把握了全局，可快速認(rèn)識自己未知的一些因素，防止在考察細節(jié)的時候陷入“死邏輯”中。

(7)警惕“過早優(yōu)化”。首先讓它運行起來，再考慮變得更快——但只有在自己必須這樣做、而且經(jīng)證實在某部分代碼中的確存在一個性能瓶頸的時候，才應(yīng)進行優(yōu)化。除非用專門的工具分析瓶頸，否則很有可能是在浪費自己的時間。性能提升的隱含代價是自己的代碼變得難于理解，而且難于維護。

(8)請記住，閱讀代碼的時間比寫代碼的時間多得多。思路清晰的設(shè)計可獲得易于理解的程序，但注釋、細致的解釋以及一些示例往往具有不可估量的價值。無論對你自己，還是對后來的人，它們都是相當(dāng)重要的。如對此仍有懷疑，那么請試想自己試圖從聯(lián)機Java文檔里找出有用信息時碰到的挫折，這樣或許能將你說服。

(9)如認(rèn)為自己已進行了良好的分析、設(shè)計或者實施，那么請稍微更換一下思維角度。試試邀請一些外來人士——并不一定是專家，但可以是來自本公司其他部門的人。請他們用完全新鮮的眼光考察你的工作，看看是否能找出你一度熟視無睹的問題。采取這種方式，往往能在適合修改的階段找出一些關(guān)鍵性的問題，避免產(chǎn)品發(fā)行后再解決問題而造成的金錢及精力方面的損失。

(10)良好的設(shè)計能帶來的回報。簡言之，對于一個特定的問題，通常會花較長的時間才能找到一種恰當(dāng)?shù)慕鉀Q方案。但一旦找到了正確的方法，以后的工作就輕松多了，再也不用經(jīng)歷數(shù)小時、數(shù)天或者數(shù)月的痛苦掙扎。我們的努力工作會帶來的回報(甚至無可估量)。而且由于自己傾注了大量心血，終獲得一個出色的設(shè)計方案，成功的快感也是令人心動的。堅持抵制草草完工的誘惑——那樣做往往得不償失。