(1)在現成類的基礎上創建新類時，請首先選擇“新建”或“創作”。只有自己的設計要求必須繼承時，才應考慮這方面的問題。若在本來允許新建的場合使用了繼承，則整個設計會變得沒有必要地復雜。
(2)用繼承及方法覆蓋來表示行為間的差異，而用字段表示狀態間的區別。一個非常極端的例子是通過對不同類的繼承來表示顏色，這是應該避免的：應直接使用一個“顏色”字段。
(3)為避免編程時遇到麻煩，請保證在自己類路徑指到的任何地方，每個名字都僅對應一個類。否則，編譯器可能先找到同名的另一個類，并報告出錯消息。若懷疑自己碰到了類路徑問題，請試試在類路徑的每一個起點，搜索一下同名的.class文件。
(4)在Java 1.1 AWT中使用事件“適配器”時，特別容易碰到一個陷阱。若覆蓋了某個適配器方法，同時拼寫方法沒有特別講究，的結果就是新添加一個方法，而不是覆蓋現成方法。然而，由于這樣做是完全合法的，所以不會從編譯器或運行期系統獲得任何出錯提示——只不過代碼的工作就變得不正常了。
(5)用合理的設計方案消除“偽功能”。也就是說，假若只需要創建類的一個對象，就不要提前限制自己使用應用程序，并加上一條“只生成其中一個”注釋。請考慮將其封裝成一個“獨生子”的形式。若在主程序里有大量散亂的代碼，用于創建自己的對象，請考慮采納一種創造性的方案，將些代碼封裝起來。
(6)警惕“分析癱瘓”。請記住，無論如何都要提前了解整個項目的狀況，再去考察其中的細節。由于把握了全局，可快速認識自己未知的一些因素，防止在考察細節的時候陷入“死邏輯”中。
(7)警惕“過早優化”。首先讓它運行起來，再考慮變得更快——但只有在自己必須這樣做、而且經證實在某部分代碼中的確存在一個性能瓶頸的時候，才應進行優化。除非用專門的工具分析瓶頸，否則很有可能是在浪費自己的時間。性能提升的隱含代價是自己的代碼變得難于理解，而且難于維護。
(8)請記住，閱讀代碼的時間比寫代碼的時間多得多。思路清晰的設計可獲得易于理解的程序，但注釋、細致的解釋以及一些示例往往具有不可估量的價值。無論對你自己，還是對后來的人，它們都是相當重要的。如對此仍有懷疑，那么請試想自己試圖從聯機Java文檔里找出有用信息時碰到的挫折，這樣或許能將你說服。
(9)如認為自己已進行了良好的分析、設計或者實施，那么請稍微更換一下思維角度。試試邀請一些外來人士——并不一定是專家，但可以是來自本公司其他部門的人。請他們用完全新鮮的眼光考察你的工作，看看是否能找出你一度熟視無睹的問題。采取這種方式，往往能在最適合修改的階段找出一些關鍵性的問題，避免產品發行后再解決問題而造成的金錢及精力方面的損失。
(10)良好的設計能帶來的回報。簡言之，對于一個特定的問題，通常會花較長的時間才能找到一種最恰當的解決方案。但一旦找到了正確的方法，以后的工作就輕松多了，再也不用經歷數小時、數天或者數月的痛苦掙扎。我們的努力工作會帶來的回報(甚至無可估量)。而且由于自己傾注了大量心血，最終獲得一個出色的設計方案，成功的快感也是令人心動的。堅持抵制草草完工的誘惑——那樣做往往得不償失。