]]>
]]>
原文地址Q?a target="_blank">接口和抽象类的定义方式D例说?/font>
接口定义
关于java的接口定义方式，以下三种情况下可以采用接口定义方式：
1. 接口中声明的变量全部为final 和staticcd的，q且q个接口的作用在于定义一些g能改变的变量?br>举个例子Q?br>public interface ObjectConstants{
public static final String SPACE = new String(" ");
public static final char FORMFEED = '\f';
}
2. 接口中只定义可供实现的抽象方?br>EventListener.java
public interface EventListener {
public void handleEvent(Event evt);
}
Runnable.java
package java.lang;
public interface Runnable {
public abstract void run();
}
3. q有一U方式是上述两种方式的组合，如非必要一般会这样一个接口定义拆分成两个接口定义
抽象cȝ定义
1. 如果一个类包含一个接口但是不完全实现接口定义的方法，那么该类必须定义成abstract?br>例如InputStream.javacȝ定义方式Q?br>package java.io;
public abstract class InputStream implements Closeable {
// SKIP_BUFFER_SIZE is used to determine the size of skipBuffer
private static final int SKIP_BUFFER_SIZE = 2048;
// skipBuffer is initialized in skip(long), if needed.
private static byte[] skipBuffer;
public abstract int read() throws IOException;
public int read(byte b[]) throws IOException {
return read(b, 0, b.length);
}
public int read(byte b[], int off, int len) throws IOException {
if (b == null) {
throw new NullPointerException();
} else if ((off < 0) || (off > b.length) || (len < 0) ||
((off + len) > b.length) || ((off + len) < 0)) {
throw new IndexOutOfBoundsException();
} else if (len == 0) {
return 0;
}
int c = read();
if (c == -1) {
return -1;
}
b[off] = (byte)c;
int i = 1;
try {
for (; i < len ; i++) {
c = read();
if (c == -1) {
break;
}
if (b != null) {
b[off + i] = (byte)c;
}
}
} catch (IOException ee) {
}
return i;
}
public long skip(long n) throws IOException {
long remaining = n;
int nr;
if (skipBuffer == null)
skipBuffer = new byte[SKIP_BUFFER_SIZE];
byte[] localSkipBuffer = skipBuffer;
if (n <= 0) {
return 0;
}
while (remaining > 0) {
nr = read(localSkipBuffer, 0,
(int) Math.min(SKIP_BUFFER_SIZE, remaining));
if (nr < 0) {
break;
}
remaining -= nr;
}
return n - remaining;
}
public int available() throws IOException {
return 0;
}
public void close() throws IOException {}
public synchronized void mark(int readlimit) {}
public synchronized void reset() throws IOException {
throw new IOException("mark/reset not supported");
}
public boolean markSupported() {
return false;
}
}
2. 抽象cȝҎ体中只定义抽象的ҎQ例如AbstractMethodError.java
package java.lang;
public class AbstractMethodError extends IncompatibleClassChangeError {
public AbstractMethodError() {
super();}
public AbstractMethodError(String s) {
super(s); }
}
]]>
]]>
<摘自天极|?gt;
2007-08-13 09:09 作者： Senton 出处Q?天极Yesky软g频道 责Q~辑Q?a >方舟
(1) cd首字母应该大写。字Dc方法以及对?句柄)的首字母应小写。对于所有标识符Q其中包含的所有单词都应紧靠在一P而且大写中间单词的首字母。例如：
ThisIsAClassName
thisIsMethodOrFieldName
若在定义中出C常数初始化字W，则大写static final基本cd标识W中的所有字母。这样便可标志出它们属于~译期的常数?
Java?Package)属于一U特D情况：它们全都是小写字母，即便中间的单词亦是如此。对于域名扩展名Uͼ如comQorgQnet或者edu{，全部都应写(q也是Java 1.1和Java 1.2的区别之一)?
(2) Z常规用途而创Z个类Ӟ请采?#8220;l典形式”Qƈ包含对下q元素的定义Q?
equals()
hashCode()
toString()
clone()(implement Cloneable)
implement Serializable
(3) 对于自己创徏的每一个类Q都考虑|入一个main()Q其中包含了用于试那个cȝ代码。ؓ使用一个项目中的类Q我们没必要删除试代码。若q行了Q何Ş式的改动Q可方便地返回测试。这些代码也可作为如何用类的一个示例用?
(4) 应将Ҏ设计成简要的、功能性单元，用它描述和实C个不q箋的类接口部分。理x况下Q方法应明扼要。若长度很大Q可考虑通过某种方式其分割成较短的几个Ҏ。这样做也便于类内代码的重复使用(有些时候，Ҏ必须非常大，但它们仍应只做同L一件事??(5) 设计一个类Ӟ误w处Cؓ客户E序员考虑一?cȝ使用Ҏ应该是非常明的)。然后，再设w处Cؓ理代码的h考虑一?预计有可能进行哪些Ş式的修改Q想想用什么方法可把它们变得更??
(6) 使类可能短精悍，而且只解决一个特定的问题。下面是对类设计的一些徏议：
■一个复杂的开兌句：考虑采用“多Ş”机制
■数量众多的Ҏ涉及到类型差别极大的操作Q考虑用几个类来分别实?
■许多成员变量在特征上有很大的差别：考虑使用几个c??
(7) 让一切东襉K可能地“U有”——private。可使库的某一部分“公共?#8221;(一个方法、类或者一个字D늭{?Q就永远不能把它拿出。若拿出Q就可能破坏其他人现有的代码Q他们不得不重新编写和设计。若只公布自己必d布的Q就可放心大胆地改变其他M东西。在多线E环境中Q隐U是特别重要的一个因素——只有private字段才能在非同步使用的情况下受到保护?
(8) 谨惕“巨大对象l合?#8221;。对一些习惯于序~程思维、且初涉OOP领域的新手，往往喜欢先写一个顺序执行的E序Q再把它嵌入一个或两个巨大的对象里。根据编E原理，对象表达的应该是应用E序的概念，而非应用E序本n?
(9) 若不得已q行一些不太雅观的~程Q至应该把那些代码|于一个类的内部?
(10) M时候只要发现类与类之间l合得非常紧密，需要考虑是否采用内部c，从而改善编码及l护工作(参见W?4?4.1.2节?#8220;用内部类改进代码”)?
(11) 可能细致地加上注释Qƈ用javadoc注释文档语法生成自己的程序文档?
(12) 避免使用“术数字”Q这些数字很难与代码很好地配合。如以后需要修改它Q无疑会成ؓ一场噩梦，因ؓҎ不知?#8220;100”到底是指“数组大小”q是“其他全然不同的东?#8221;。所以，我们应创Z个常敎ͼqؓ其用具有说服力的描q性名Uͼq在整个E序中都采用常数标识W。这样可使程序更易理解以及更易维护?
(13) 涉及构徏器和异常的时候，通常希望重新丢弃在构建器中捕LM异常——如果它造成了那个对象的创徏p|。这样一来，调用者就不会以ؓ那个对象已正地创徏Q从而盲目地l箋?
(14) 当客L序员用完对象以后Q若你的c要求进行Q何清除工作，可考虑清除代码置于一个良好定义的Ҏ里，采用cM于cleanup()q样的名字，明确表明自己的用途。除此以外，可在cd攄一个boolean(布尔)标记Q指出对象是否已被清除。在cȝfinalize()Ҏ里，L定对象已被清除，q已丢弃了从RuntimeExceptionl承的一个类(如果q没有的?Q从而指Z个编E错误。在采取象这LҎ之前Q请定finalize ()能够在自qpȝ中工?可能需要调用System.runFinalizersonExit(true)Q从而确保这一行ؓ)?
(15) 在一个特定的作用域内Q若一个对象必L?非由垃圾攉机制处理)Q请采用下述ҎQ初始化对象;若成功，则立卌入一个含有finally从句的try块，开始清除工作?
(16) 若在初始化过E中需要覆?取消)finalize()Q请C调用super.finalize()(若Object属于我们的直接超c，则无此必?。在对finalize()q行覆盖的过E中Q对super.finalize()的调用应属于最后一个行动，而不应是W一个行动，q样可确保在需要基cȝ件的时候它们依然有效?
(17) 创徏大小固定的对象集合时Q请它们传输至一个数l?若准备从一个方法里q回q个集合Q更应如此操?。这样一来，我们可享受到数l在~译期进行类型检查的好处。此外，Z用它们，数组的接收者也许ƈ不需要将对象“造型”到数l里?
(18) 量使用interfacesQ不要用abstractcR若已知某样东西准备成ؓ一个基c，那么W一个选择应是其变成一个interface(接口)。只有在不得不用方法定义或者成员变量的时候，才需要将其变成一个abstract(抽象)cR接口主要描qC客户希望做什么事情，而一个类则致力于(或允?具体的实施细节?
(19) 在构建器内部Q只q行那些对象设为正状态所需的工作。尽可能地避免调用其他方法，因ؓ那些Ҏ可能被其他h覆盖或取消，从而在构徏q程中生不可预知的l果(参见W?章的详细说明)?
(20) 对象不应只是单地容纳一些数?它们的行Z应得到良好的定义?
(21) 在现成类的基上创建新cLQ请首先选择“新徏”?#8220;创作”。只有自q设计要求必须l承Ӟ才应考虑q方面的问题。若在本来允许新建的场合使用了承，则整个设计会变得没有必要地复杂?
(22) 用承及Ҏ覆盖来表C为间的差异，而用字段表示状态间的区别。一个非常极端的例子是通过对不同类的承来表示颜色Q这是绝对应该避免的Q应直接使用一?#8220;颜色”字段?
(23) 为避免编E时遇到ȝQ请保证在自q路径指到的Q何地方，每个名字都仅对应一个类。否则，~译器可能先扑ֈ同名的另一个类Qƈ报告出错消息。若怀疑自qCc\径问题，误试在c\径的每一个v点，搜烦一下同名的.class文g?
(24) 在Java 1.1 AWT中用事?#8220;适配?#8221;Ӟ特别Ҏ到一个陷阱。若覆盖了某个适配器方法，同时拼写Ҏ没有特别讲究Q最后的l果是新添加一个方法，而不是覆盖现成方法。然而，׃q样做是完全合法的，所以不会从~译器或q行期系l获得Q何出错提C——只不过代码的工作就变得不正怺?
(25) 用合理的设计Ҏ消除“伪功?#8221;。也是_假若只需要创建类的一个对象，׃要提前限制自׃用应用程序，q加上一?#8220;只生成其中一?#8221;注释。请考虑其装成一?#8220;独生?#8221;的Ş式。若在主E序里有大量散ؕ的代码，用于创徏自己的对象，误虑采纳一U创造性的ҎQ将些代码封装v来?
(26) 警惕“分析瘫痪”。请CQ无论如何都要提前了解整个项目的状况Q再去考察其中的细节。由于把握了全局Q可快速认识自己未知的一些因素，防止在考察l节的时候陷?#8220;死逻辑”中?
(27) 警惕“q早优化”。首先让它运行v来，再考虑变得更快——但只有在自己必这样做、而且l证实在某部分代码中的确存在一个性能瓉的时候，才应q行优化。除非用专门的工具分析瓶颈，否则很有可能是在费自己的时间。性能提升的隐含代h自己的代码变得难于理解，而且难于l护?
(28) 误住，阅读代码的时间比写代码的旉多得多。思\清晰的设计可获得易于理解的程序，但注释、细致的解释以及一些示例往往h不可估量的h倹{无论对你自己，q是对后来的人，它们都是相当重要的。如Ҏ仍有怀疑，那么误惌p图从联机Java文档里找出有用信息时到的挫折，q样或许能将你说服?
(29) 如认己已q行了良好的分析、设计或者实施，那么L微更换一下思维角度。试试邀请一些外来h士——ƈ不一定是专家Q但可以是来自本公司其他部门的h。请他们用完全新鲜的眼光考察你的工作Q看看是否能扑և你一度熟视无睹的问题。采取这U方式，往往能在最适合修改的阶D|Z些关键性的问题Q避免品发行后再解决问题而造成的金钱及_֊斚w的损失?
(30) 良好的设计能带来最大的回报。简a之，对于一个特定的问题Q通常会花较长的时间才能找CU最恰当的解x案。但一旦找C正确的方法，以后的工作就L多了Q再也不用经历数时、数天或者数月的痛苦挣扎。我们的努力工作会带来最大的回报(甚至无可估量)。而且׃自己倾注了大量心血Q最l获得一个出色的设计ҎQ成功的快感也是令h心动的。坚持抵制草草完工的诱惑——那样做往往得不偿失?/p>