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

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

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

@23452
周一發(fā)給你.

@FinalFantasy
請留下郵箱地址。我會發(fā)過去。

@乾為天
@spermakert
源代碼已經(jīng)發(fā)到你們的郵箱里了，請查收。

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

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

我想看了這篇文章你應(yīng)該會對如何實現(xiàn)模擬實現(xiàn)多重繼承這個技巧本身有所領(lǐng)悟，至于這個技巧的應(yīng)用時機(jī)，我確實很難用一個短小的例子恰當(dāng)?shù)某尸F(xiàn)出來－－因為如果一個小例子需要用到多重繼承，我完全可以重構(gòu)它讓他不用多重繼承就可以實現(xiàn)，因為重構(gòu)的代價并不大。

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

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

@wolfsquare
模擬多重繼承的這個技術(shù)是為解決一個實際項目中的問題而產(chǎn)生的，當(dāng)然有他的實際意義。

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

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

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

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

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

@wolfsquare
我在文章的最后也提到過了，
“當(dāng)然，其實這個信息傳遞服務(wù)的例子不用多重繼承也能實現(xiàn)”。
這么寫只是舉個例子，設(shè)計良好的Java應(yīng)用絕對不會用到多重繼承。

@Harryson
怎么叫"很容易"，那家活可是"相當(dāng)容易"！

這么強(qiáng)，我到官方網(wǎng)站上看看去。

@zn_cn_2
謝謝，我下在到了

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

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

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

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

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

@dudu
謝謝Dudu

上面兩題的答案都不對吧?
第一題是初中物理水平:
設(shè)通訊員的速度為v,
以隊伍為參照物,則通信員從隊首到隊尾時,相對于隊伍的速度為(v+1),從隊尾回隊首時,相對于隊伍的速度為(v-1).通信員無論時從隊頭到隊尾還是從隊尾到對頭,相對于退伍走過的路程都是100m.因此,通信員所花的時間為:y = 100/(v+1)+100/(v-1).而在這段時間里,隊伍前進(jìn)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

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

這種縱橫交叉邏輯,離散數(shù)學(xué)中見得多了.

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

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

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