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

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

(3)為避免編程時(shí)遇到麻煩，請保證在自己類路徑指到的任何地方，每個(gè)名字都僅對應(yīng)一個(gè)類。否則，編譯器可能先找到同名的另一個(gè)類，并報(bào)告出錯(cuò)消息。若懷疑自己碰到了類路徑問題，請?jiān)囋囋陬惵窂降拿恳粋€(gè)起點(diǎn)，搜索一下同名的.class文件。

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

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

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

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

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

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

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