|
已锁定 主题：Java API设计指南
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-11-11
语句很通顺，没感觉出有描述错误的地方，多谢楼主
挑点小毛病 引用 译注：java.nio和java.lang.ProcessBuilder是指JDK6中的包，害得我在JDK1.4中找了半天，参见http://download.java.net/jdk6/doc/api/java/lang/ProcessBuilder.html，这里所谓的thing和Thing也不是真有这个方法和类，而是ProcessBuilder中的command和command(List)等多个方法。 其实java.nio是1.4的，java.lang.ProcessBuilder是1.5的 |
| 返回顶楼 | |
|
发表时间：2006-11-30
谢谢楼主,一直想找这方面的资料,今天终于找到了
|
| 返回顶楼 | |
|
发表时间：2006-12-01
引用 不要实现Cloneable, 即使想某一个类支持对象的复制，这个接口也没有太多的价值，如果真想支持复制功能，提供一个复制构造函数或者是一个static方法来复制对象，又或者提供一个static的工厂方法来创建对象，也会更加有效。例如想让Banana这个类拥有clone的能力，可以使用代码如下： public Banana(Banana b) { // copy constructor this(b.colour, b.length); } // ...or... public static Banana newInstance(Banana b) { return new Banana(b.colour, b.length); } 构造函数的优点就在于子类可以调用父类的构造函数。static函数则是可以返回具体类的子类实现。 <<thinking in java>>附录A针对克隆有很详细的说明，这样做是不对的（我先去再看看）。 |
| 返回顶楼 | |
|
发表时间：2006-12-01
这个观点，其实我也是不赞同的
我的习惯是另外提供一个IClonable接口 有一个clone方法 强迫用户实现Public的clone 这样处理可能更好一些 以前和作者沟通，他也认为这段话有欠妥当 他的本意是反对Java的Clonable接口，而不是反对clone 由于这些交流是在文章翻译以后，所以没有更新 正如前面的朋友所说 加太多的个人观点 对原文也不太尊重! |
| 返回顶楼 | |
|
发表时间：2006-12-01
这个观点，其实我也是不赞同的
我的习惯是另外提供一个IClonable接口 有一个clone方法 强迫用户实现Public的clone 这样处理可能更好一些 以前和作者沟通，他也认为这段话有欠妥当 他的本意是反对Java的Clonable接口，而不是反对clone 由于这些交流是在文章翻译以后，所以没有更新 正如前面的朋友所说 加太多的个人观点 对原文也不太尊重! |
| 返回顶楼 | |
|
发表时间：2006-12-01
先下载看看
|
| 返回顶楼 | |
|
发表时间：2006-12-11
收了谢谢拉
|
| 返回顶楼 | |
|
发表时间：2006-12-13
好文章
|
| 返回顶楼 | |
|
发表时间：2007-02-02
这篇文章是不错的文章。
看了两遍，都有不同的感想。 首先，对译著的看法。 同意上面的观点，个人的看法有些多。 但是我想个人有看法也要表达出来，和大家交流，这样才好。 所以我想是不是可以在原文的地方只是标注出（1）之类的脚注， 在后面将个人的看法统一写出来。 其次，我对API设计的看法。 上面说的问题，在开发的过程中，遇到了一些。 例如protected,private,public等关键字的使用； 到底提供多少API等问题。这些问题也的确给我后来的维护带来了一些麻烦。 因为经验较少，所以在设计的时候，经常采用的是参照jdk的方法。 看看jdk是如何命名的，看看jdk是如何设计的。这个方法在我的工作中的确对我的帮助不小，而且说服用户也较容易。 这使我想到楼主的另一个文章，模式用还是不用的文章。 在设计的时候，我有时候尽量采用一些模式，也是为了说服用户，让用户容易理解。 尽管有时候用户对这个模式究竟是什么也不是十分清楚。 最后谢谢楼主的翻译。希望楼主继续能够翻译出好的文章。如果希望我的帮助，我也愿意帮助楼主作一些工作。 |
| 返回顶楼 | |
|
发表时间：2007-02-02
谢谢楼主呀
|
| 返回顶楼 | |
