Java抽象类和接口

        一个Java接口(Interface)是一些方法特征的集合，一个接口只有方法的特征，而没有方法的实现，因此当这些方法在不同的地方被实现时，可以具有完全不同的行为。
        比如java.lang.Runnable是一个接口，其源代码为：

public interface Runnable {
	public abstract void run();
} 

        在Java语言规范中，一个方法的特征仅包括方法的名字、参数的数目、种类和顺序不同，而不包括方法的返回类型、参数的名字以及所抛出的异常。当Java编译器检查方法的重载(Overload)时，会根据这些条件判断两个方法是否是重载方法。但是在Java编译器检查方法的重写(Override)时，会进一步检查两个方法(超类和子类)的返回类型和抛出异常是否相同。
        说明：重载是同一个类的不同方法之间由于其方法名相同，参数的数目、种类、顺序的不同；当方法被调用时，JVM根据不同的参数样式来选择合适的方法来执行。重写(Override)，也就是覆盖，是子类将父类中的方法在子类中重新实现。子类必须和父类完全相同，并且其可见性不能小于父类的可见性，即若父类是protected则子类只能是protected/public的；若父类有异常抛出，子类抛出的异常必须和父类异常相同或是其子类异常。
        Java接口的方法必须是public abastract的，且接口不能有构造方法；变量必须是是public static final的(实际上就是常量)。
        Java接口的常见用法:
        (1).单方法接口，如java.lang.Runnable、java.awt.event.ActionListener等
        (2).标识接口，如java.io.Serializable等
        (3).常量接口，即使有Java接口来声明一些常量，如com.lcr.sat.SatConstants
        在Java语言中，类有两种，一种是具体类，另一种是抽象类。具体类可以实例化，抽象类不可以实例化。抽象类仅提供一个类型的部分实型。抽象类可以有实例变量，以及一个或多个构造方法。抽象类应该拥有尽可能多的共同代码，拥有尽可能少的数据。
        面向对象设计的一个最核心的原则OCP(开闭原则Open-Closed Principle)，抽象类是其中的关键所在。
        在Java语言中，继承可以分为两种：一种是类对接口的实现，称作接口继承；另一种是类对类的继承，称作实现继承。继承代表“一般化/特殊化”的关系，其中基类代表一般，而衍生类代表特殊，衍生将基类特殊化或扩展化。使用继承关系的条件如下：
        (1).has-a使用聚合关系，is-a使用继承关系。
        has-a是对象和它的成员的从属关系 ,同一种类的对象，通过它们的属性的不同值来区别。比如一台PC机的操作系统是Windows，另一台PC机的操作系统是Linux。操作系统是PC机的一个成员变量，根据这一成员变量的不同值，可以区分不同的PC机对象。
。
        is-a是一种继承关系。比如PC机是计算机，工作站也是计算机。PC机和工作站是两种不同类型的计算机，但都继承了计算机的共同特性。因此在用Java语言实现时，应该将PC机和工作站定义成两种类，均继承计算机类。
        (2).子类需要扩展超类，但不必重写(Override)超类的方法。
        从语法定义看抽象类和接口

public abstract class DemoAbstractClass {
	abstract void methodOne ();
	abstract void methodTwo ();
	void methodThree () {
		/**  */
	}
}

public interface DemoInterface {
	void methodOne ();
	void methodTwo ();
	void methodThree ();
}

        在abstract class方式中，DemoAbstractClass可以有自己的数据成员，也可以有非 abstract的成员方法，而在interface方式的实现中，DemoInterface只能够有静态的不能被修改的数据成员（也就是必须是public static final 的，不过在interface中一般不定义数据成员），所有的成员方法都是abstract的。从某种意义上说，interface是一种特殊形式的 abstract class。
        从设计理念看抽象类和接口

abstract class DoorAbstractClass{
	abstract void open();
	abstract void close()；
} 

interface DoorInterface{
	void open();
	void close();
} 

         其他具体的Door类型可以extends使用abstract class方式定义的DoorAbstractClass或者implements使用interface方式定义的DoorInterface，抽象类和接口看起来并没有什么区别。
         如果现在要求Door要具有报警的功能，我们可以在抽象类Door中增加一个报警方法alerm()，如下：

abstract class DoorAbstractClass{
	abstract void open();
	abstract void close()；
	abstract void alerm()；
} 

interface DoorInterface{
	void open();
	void close();
	void alerm();
} 

         然后再通过子类实现抽象类或接口即可。

class AlarmDoor extends DoorAbstractClass{
	void open(){…}
	void close(){…}
	void alerm(){…}
} 

class AlarmDoor implements DoorInterface{
	void open(){…}
	void close(){…}
	void alerm(){…}
}

         这种方法违反了面向对象设计中的一个核心原则ISP(接口隔离原则 Interface Segregation Principle)，在Door的定义中把Door概念本身固有的行为方法和另外一个概念"报警器"的行为方 法混在了一起。这样引起的一个问题是那些仅仅依赖于Door这个概念的模块会因为"报警器"这个概念的改变（比如修改alarm方法的参数）而改变，反之依然。
         既然open、close和alarm属于两个不同的概念，根据ISP原则应该把它们分别定 义在代表这两个概念的抽象类中。定义方式有：这两个概念都使用abstract class 方式定义；两个概念都使用interface方式定义；一个概念使用abstract class方式定义，另一个概念使用interface方式定义。
         由于Java语言不支持多重继承，所以两个概念都使用abstract class方式定义是不可行的。后面两种方式都是可行的，但是对于它们的选择却反映出对于问题领域中的概念本质的理解、对于设计意图的反映是否正确、合理。
         如果两个概念都使用interface方式来定义，那么就反映出两个问题：1、我们可能没有 理解清楚问题领域，AlarmDoor在概念本质上到底是Door还是报警器？2、如果我们对于问题领域的理解没有问题，比如：我们通过对于问题领域的分 析发现AlarmDoor在概念本质上和Door是一致的。那么都使用interface方式实现时，就没有能够正确的揭示我们的设计意图，因为在这两个概念的定义上反映不出上述含义。
         如果我们对于问题领域的理解是：AlarmDoor在概念本质上是Door，同时它有具有报警的功能。我们该如何来设计、实现来明确的反映出我们的意思呢？前面已经说过，abstract class在Java语言中表示一种继承关系，而继承关系在本质上是"is-a"关系。所以对于Door这个概念，我们应该使用abstarct class方式来定义。另外，AlarmDoor又具有报警功能，说明它又能够完成报警概念中定义的行为，所以报警概念可以通过interface方式定义。如下所示：

abstract class Door {
	abstract void open();
	abstract void close()；
}
interface Alarm {
	void alarm();
}
class Alarm Door extends Door implements Alarm{
	void open(){…}
	void close(){…}
	void alarm(){…}
}

        总结：其实abstract class表示的是"is-a"关系，interface表示的是"like-a"关系，大家在选择时可以作为一个依据，当然这是建立在对问题领域的理解上的，比如：如果我们认为AlarmDoor在概念本质上是报警器，同时又具有Door的功能，那么上述的定义方式就要反过来了。
        举例1.
        我定义了一个抽象类：BOEntity，该类对应于数据库中的一条记录，即通过set/get方式来设置/获得字段对应的字段值。

public abstract class BOEntity {
	Hashtable values;

	public BOEntity() {
		values = new Hashtable();
	}

	public Object getField(String name) {
		return values.get(name);
	}

	public int getIntField(String name) {
		return ((Integer) values.get(name)).intValue();
	}

	public long getLongField(String name) {
		Object l = values.get(name);
		if (l instanceof Long) {
			return ((Long) l).longValue();
		} else if (l instanceof Integer) {
			return ((Integer) l).intValue();
		}
		return Long.MIN_VALUE;
	}

	public String getStringField(String name) {
		if (values.get(name) == null) {
			return "";
		}
		return String.valueOf(values.get(name));
	}

	public boolean getBooleanField(String name) {
		Object v = values.get(name);
		if (v == null) {
			v = new Boolean(false);
		}
		return ((Boolean) v).booleanValue();
	}

	public void setField(String name, Object data) {
		values.put(name, data);
	}
}

        在我们程序的其他地方，我们使用User、Gorup、LogEntry分别继承了该抽象类BOEntity，并实现了IUser、IGroup、ILogEntry接口。

public class LogEntry extends BOEntity implements ILogEntry, LCRConstants {
	IFieldDef getFieldDef(String fieldname);
}

        说明：这里对于抽象类和接口的理解与AlarmDoor中的理解刚好反了过来，即这里的LogEntry本质上"is-a" BOEntity，另外它还有一些ILogEntry的功能。LogEntry调用其父类的方法可以获得给定字段名称的字段值，但是，通过ILogEntry定义的getFieldDef(String fieldName)方法可以取得LogEntry的字段定义，包括字段的名称、在数据库中对应的列名称、字段类型、数据长度、是否必须等ILogEntry才有的功能。
        若User继承BOEntity而实现IUser接口的时候，User调用父类BOEntity取得其值的方式是一样的，同样可以通过IUser定义不同于ILogEntry的方法。
        User user = new User();然后给user添加name/value，并将User的name/value的形式调用bo的setField()方法，这样在以后需要值的地方就可以直接通过bo来获得；当需要查看User类的字段的详细信息的时候，可以使用IUser定义而User类自身实现的方法来查看了。
        总结：抽象类为子类提供了统一的数据调用，而接口提供额外的、不同于其他实现的附件功能。

<<OVER>>