@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官方网站.
呵呵,让大家见笑了.翻译的是有点业余:)
谢谢给出批评意见,指出翻译错误.上面你提到的我已经修改了.
再次谢谢大家...