@mhrjxh
第一個問題：
57*53是大圖片中的每一個組成幀的大小。并不是算出來的，而是事先就知道的。
第二個問題：
查看資源的路徑是否正確。

@Mir
最近在忙畢業設計和答辯，所以不能馬上回復你。星期二發給你，好嗎？

對開源的東西我一直抱著支持的態度，可惜工作比較忙，沒什么時間去開源。

@23452
周一發給你.

@FinalFantasy
請留下郵箱地址。我會發過去。

@乾為天
@spermakert
源代碼已經發到你們的郵箱里了，請查收。

@wolfsquare
我的文章讓你感到迷惑了？那是我寫得不好。令大家看不懂或者模棱兩可決不是我的本意。

文中的例子是實際項目的簡化，目的是能用簡單的代碼說明如何模擬多重繼承。

我想看了這篇文章你應該會對如何實現模擬實現多重繼承這個技巧本身有所領悟，至于這個技巧的應用時機，我確實很難用一個短小的例子恰當的呈現出來－－因為如果一個小例子需要用到多重繼承，我完全可以重構它讓他不用多重繼承就可以實現，因為重構的代價并不大。

技巧本身我想大家都看得懂、學得會，但是有沒有機會使用，就要看你實際開發中能不能碰到像我一樣類似得情況或更復雜得情況了。

如果你連模擬多重繼承這個技巧本身也沒有看懂，請您告訴我，我會重新思考，重寫本篇文章。因為寫這篇文章的目的只是想教大家這么一個技術，應用時機還得大家從實踐中去體會。

@wolfsquare
模擬多重繼承的這個技術是為解決一個實際項目中的問題而產生的，當然有他的實際意義。

實際項目中由于一開始的設計存在問題，導致我們后期開發時不得不引入多重繼承機制，因為這么做付出的代價最小。我知道最好的解決方案當然是重構這個工程，或者修改一大堆的接口和類，然后重新測試。同志們，如果你是項目經理，你會這么做嗎？？

項目是以成敗論英雄的，做項目最講究用最小的投入達成既定目標。在我的項目中，多重繼承這個解決方案付出的代價最小，盡管還存在其他許多解決方法，但是我們最后還是決定保留原來不好的設計，采用多重繼承解決問題。

好與壞之間沒有嚴格的界限，同一樣東西放到不同環境中，效果和評價是不一樣的。就像我在文章開頭說的一樣：“在一般的開發中，Java的單繼承限制一般不會引起什么問題。實際上，需要使用多重繼承往往意味著糟糕的設計。”但是在我的這個項目中，多重繼承確實最佳解決方案。

我很抱歉給出的例子可能不是很恰當，因為這是我自己編的一個例子，目的是讓例子更好懂，如果我把項目里的代碼拿出來，是的，那確實很恰當，但是那樣做的話會涉及到21個類3個接口，類里面最小的也有60句，多的有2400句代碼，我這樣貼出來，一我想我說不明白事情了－－實際問題確實太復雜，二恐怕要花費你很多寶貴的時間，更糟糕的是，你還不一定能看明白。并且我也違反了公司的竟業守則和保密協議。

請原諒我一時間確實找不出更好的例子，因為需要用到多重繼承的情況極少極少，只在某些特殊情況下才會選擇使用多重繼承來解決問題(例如我的這個項目，使用多重繼承代價最小)。我寫這篇文章的目的是想告訴大家Java存在這么一種技巧可以模擬多重繼承，如果有一天，你的項目碰到了和我類似的情況，你就可以不必重構你的項目或者對項目大刀闊斧了，因為有一種在某些特定情況下很有用的技巧－－模擬多重繼承。

@wolfsquare
我在文章的最后也提到過了，
“當然，其實這個信息傳遞服務的例子不用多重繼承也能實現”。
這么寫只是舉個例子，設計良好的Java應用絕對不會用到多重繼承。

@Harryson
怎么叫"很容易"，那家活可是"相當容易"！

這么強，我到官方網站上看看去。

@zn_cn_2
謝謝，我下在到了

我用Eclipse。不過在去年12月分召開的Java技術大會上我就體驗NetBeans5.0，感覺很震撼，可惜公司開發指定使用Eclipse，所以就沒有怎么使用NetBeans5.0。關于NetBeans5.0還有一點缺憾就是目前還沒有相應的J2ME插件，我還要使用NetBeans4.1開發J2ME程序。
ANT我是經常用，用它來完成構建和部署得心應手。離不開Ant。

我覺得為什么大家愛用微軟的東西，并不是微軟的產品好，而是微軟的產品在易用性上做得好，因為易用，大家就都去用，久而久之就形成了習慣。習慣的力量是很可怕的，并且是帶有慣性的。相比之下開源軟件功能更強，但是易用性很欠缺。這方面我很有體會。剛開始接處開源軟件時很難上手，要記得東西比較多，可是用習慣了也是非常得心應手。因此我從來不懷疑開源軟件的功能以及他的未來，相反，我更想做得是如何普及開源軟件，讓更多的人開始了解并使用開源產品，讓開源軟件能占據普通用戶PC和應用服務的半壁江山，而不只是計算機專業人士的專用工具。也許我們可以努力，從這個概念中的Java Universal開始，為開源事業貢獻一點微薄的力量。

上面的數據是你自己測的嗎？
Java到遲暮之年了嗎？我看未必。看一個語言的前途，不單單是他的性能，我認為更應該是它成功應用的案例。這就如同要讓得99分的人通過檢查試卷把分數提高到100分的難度>>讓60分的人通過檢查試卷，把分數提高到70分一樣。

對不起，我沒仔細看第一題。作者的解法是正確的。我的解法和作者的解法是兩套思路。我使用了變換參考系方法，得出的結果其實都是一樣的。

@陳朋奕
恩，做開發用不著上面那么全面的知識。還是管理員用的比較多。

@dudu
謝謝Dudu

上面兩題的答案都不對吧?
第一題是初中物理水平:
設通訊員的速度為v,
以隊伍為參照物,則通信員從隊首到隊尾時,相對于隊伍的速度為(v+1),從隊尾回隊首時,相對于隊伍的速度為(v-1).通信員無論時從隊頭到隊尾還是從隊尾到對頭,相對于退伍走過的路程都是100m.因此,通信員所花的時間為:y = 100/(v+1)+100/(v-1).而在這段時間里,隊伍前進100m.隊伍速度為1,因此有100/(v+1)+100/(v-1) = 100;
解得v = 1+sqrt(2),或 v = 1 - sqrt(2) (舍去).
因此通信員走得路程為s =v*t = (1+sqrt(2))*100 = 241.4

第二題的答案應該是9月1號.
小明說：如果我不知道的話，小強肯定也不知道
那么肯定不是6月和12月;
小強說：本來我也不知道，但是現在我知道了
那么從剩下的里面排除3月5號和9月5號;
小明說：哦，那我也知道了
那么只能是9月1號;

這種縱橫交叉邏輯,離散數學中見得多了.

好想法,支持.我這有很多開源產品,可以提供給你.
感覺與Windows Server 2003 Enterprise匹敵的還應該是Solaris.Solaris X已經開源,我這里有.

第四章正在加緊翻譯，不日將與大家見面。希望大家多提寶貴建議和意見。

@指教了
這不是我寫的,我翻譯自Groovy官方網站.
呵呵,讓大家見笑了.翻譯的是有點業余:)
謝謝給出批評意見,指出翻譯錯誤.上面你提到的我已經修改了.
再次謝謝大家...