Java语言的接口与类型安全

 

Java语言的接口与类型安全

接口是实现构件可插入性的关键，可插入构件的关键在于存在一个公用的接口，以及每个构件实现了这个接口。

　　什么是接口？

　　Java中的接口是一系列方法的声明，是一些方法特征的集合，一个接口只有方法的特征没有方法的实现，因此这些方法可以在不同的地方被不同的类实现，而这些实现可以具有不同的行为（功能）。

　　接口的两种含义：一、Java接口，Java语言中存在的结构，有特定的语法和结构；二、一个类所具有的方法的特征集合，是一种逻辑上的抽象。前者叫做“Java接口”，后者叫做“接口”。

　　在Java语言规范中，一个方法的特征仅包括方法的名字，参数的数目和种类，而不包括方法的返回类型，参数的名字以及所抛出来的异常。在Java编译器检查方法的重载时，会根据这些条件判断两个方法是否是重载方法。但在Java编译器检查方法的置换时，则会进一步检查两个方法（分处超类型和子类型）的返还类型和抛出的异常是否相同。

　　接口继承和实现继承的规则不同，一个类只有一个直接父类，但可以实现多个接口。

　　Java接口本身没有任何实现，因为Java接口不涉及表象，而只描述public行为，所以Java接口比Java抽象类更抽象化。

　　Java接口的方法只能是抽象的和公开的，Java接口不能有构造器，Java接口可以有public,静态的和final属性。

　　接口把方法的特征和方法的实现分割开来。这种分割体现在接口常常代表一个角色，它包装与该角色相关的操作和属性，而实现这个接口的类便是扮演这个角色的演员。一个角色由不同的演员来演，而不同的演员之间除了扮演一个共同的角色之外，并不要求其它的共同之处。

　　为什么使用接口？

　　两个类中的两个类似的功能，调用他们的类动态的决定一种实现，那他们提供一个抽象父类，子类分别实现父类所定义的方法。

　　问题的出现：Java是一种单继承的语言，一般情况下，哪个具体类可能已经有了一个超类，解决是给它的父类加父类，或者给它父类的父类加父类，只到移动到类等级结构的最顶端。这样一来，对一个具体类的可插入性的设计，就变成了对整个等级结构中所有类的修改。

　　接口是可插入性的保证。

　　在一个等级结构中的任何一个类都可以实现一个接口，这个接口会影响到此类的所有子类，但不会影响到此类的任何超类。此类将不得不实现这个接口所规定的方法，而其子类可以从此类自动继承这些方法，当然也可以选择置换掉所有的这些方法，或者其中的某一些方法，这时候，这些子类具有了可插入性（并且可以用这个接口类型装载，传递实现了他的所有子类）。

　　我们关心的不是那一个具体的类，而是这个类是否实现了我们需要的接口。

　　接口提供了关联以及方法调用上的可插入性，软件系统的规模越大，生命周期越长，接口使得软件系统的灵活性和可扩展性，可插入性方面得到保证。

　　类型

　　使用Java接口将软件单位与内部和外部耦合起来。使用Java接口不是具体的类进行变量的类型声明，方法的返还类型声明，参量的类型声明，以及数据类型的转换。

　　在理想的情况下，一个具体的Java类应当只实现Java接口和抽象Java类中声明的方法，而不应当给多余方法。

　　类型等级结构

　　Java接口（以及抽象类）一般用来作为一个类型的等级结构的起点。

　　如果一个类已经有了一个主要的超类型，那么通过实现一个接口，这个类可以拥有另一个次要的超类型，这种次要的超类型叫做混合类型。

　　Java接口常用方法

　　单方法接口

　　public interface Actionlistener(){

　　public abstract void actionPerformed(ActionEvent event);

　　}

　　仅且只有一个方法，只有实现了这个接口（重写这个接口中的唯一一个方法），你才有资格去事件监听器列表里注册（参数为Actionlistener类型），当事件源变动时，自动调用这个唯一的actionPerformed方法.

　　标识接口

　　是没有任何方法和属性的接口。标识接口不对实现它的类有任何语意上的要求，它仅仅表明了实现它的类属于一个特定的类型（传递）。

　　不推荐过多的使用标识接口。

常量接口

　　用Java接口来声明一些常量，然后由实现这个接口的类使用这些常量（以前在做画板的时候这么干过）。建议不要模仿这种常量接口的做法。

　　Java语言类型安全问题

　　Java是强类型的语言。这意味着Java编译器会对代码进行检查，以确定每一次赋值，每一次方法的调用是符合类型的。如果有任何不相符合的情况，Java编译器就会给出错误。

　　类型检查是基于这样一个简单的事实：每一变量的声明都给这个变量一个类型；每一个方法包括构造器的声明都给这个方法的特征。这样一来，Java编译器可以对任何的表达式推断出一个明显类型，Java编译器可以基于明显类型对类型进行检查。

　　Java语言是类型安全的。这就是说，任何被Java编译器接受的合法的Java类保证是类型安全的。换言之，在程序运行期间，不会有任何类型的错误。一个Java程序根本不可能将一个本来属于一个类型的变量当作另一个类型处理，因此也就不会产生由此而引起的错误。

　　简单的说，Java语言依靠三种机制做到了类型安全：编译期间的类型检查，自动的存储管理，数组的边界检查。

　　注：本篇大部分内容出之 阎宏 老师的《Java与模式》。

怎样设计合适的接口

摘要：我们在设计系统接口时，经常会遇到这样的问题： 
我们的接口应该提供多少方法才合适？ 
我们的接口应该提供"原子方法"还是"复合方法"？ 
我们的接口是否应该封装（或者，能否封装）所有的细节？ 
接口的设计需要考虑用户的使用习惯、使用的方便程度、使用的安全程度，根据我的编程经验，下面会详细讨论接口设计的2个需要权衡的方面：接口的单一化 & 复合化。 
接口 
接口提供了不同系统之间或者系统不同组件之间的界定。在软件中，接口提供了一个屏障，从而从实现中分离目标，从具体中分离抽象，从作者中分离用户。
站在用户的角度看，一个接口建立并命名了一个目标对象的使用方法。一些约束（例如：编译时的类型系统、运行时的异常机制及返回值）使得类作者的目的得以体现和加强。供给（affordances）指事物的被感知的真实的属性，这些属性可以决定事物使用的可能方法，供给提供了对事物操作的线索。

类设计者的一个职责便是在接口中减小约束与供给之间的隔阂、匹配目标以及一定程度上的自由度，尽可能减小错误使用目标对象的可能。

封装 
对于封装来说，远不止数据私有那么简单。在设计中，封装往往会涉及到自我包含（self-containment）。如果一个类需要你知道如何调用它方法（e.g. 在一个线程的环境中，在一个方法调用后调用另一个方法，你必须明确地同步对象），那么它的封装性就不如将所有这些全部包含并隐藏的类（e.g. 这个类是thread-safe的）好。前一个设计存在着设计的漏洞，它的许多限定条件是模糊的，而且把部分责任推给了用户，而不是让类提供者做这些工作来完成类的设计。

在空间或者时间上分离方法的执行（例如，线程，远程方法调用，消息队列），能够对设计的正确性和效率产生意义深远的影响。这种分离带来的结果是不可忽视的： 

并发引入了不确定性和环境（context）选择的开销； 
分布引入了回调的开销，这些开销可能不断增加，而且会导致错误。
这些是设计的问题，修改它们可不是象修改bug那样简单。

如果一个接口主要由存取方法（set和get方法）组成，每个方法都相应的直接指向某个私有域，那么它的封装性会很差。接口中的域存取方法通常是不会提供信息的：他们在对象的使用中不能通讯、简单化和抽象化，这通常会导致代码冗长，并且容易出错。

所以，我们首先考虑接口设计的第一个原则：

命令与查询分离（Command-Query Separation） 
要求：保证一个方法不是命令（Command）就是查询（Query）

定义：
　　查询：当一个方法返回一个值来回应一个问题的时候，它就具有查询的性质； 
　　命令：当一个方法要改变对象的状态的时候，它就具有命令的性质；

通常，一个方法可能是纯的Command模式或者是纯的Query模式，或者是两者的混合体。在设计接口时，如果可能，应该尽量使接口单一化，保证方法的行为严格的是命令或者是查询，这样查询方法不会改变对象的状态，没有副作用（side effects），而会改变对象的状态的方法不可能有返回值。也就是说：如果我们要问一个问题，那么就不应该影响到它的答案。实际应用，要视具体情况而定，语义的清晰性和使用的简单性之间需要权衡。

例如，在java.util.Iterator中，hasNext可以被看作一种查询，remove是一种命令，next合并了命令和查询： 
public interface Iterator{
boolean hasNext();
Object next();
void remove();
}

 


这里，如果不将一个Iterator对象的当前值向前到下一个的话，就不能够查询一个Iterator对象。如果没有提供一个复合方法next，我们将需要定义一系列的命令方法，例如：初始化（initialization）、继续(continuation)、访问(access)和前进(advance)，它们虽然清晰定义了每个动作，但是，客户代码过于复杂： 
for(initialization; continuation condition; advance){
... access for use ...
}

 


将Command和Query功能合并入一个方法，方便了客户的使用，但是，降低了清晰性，而且，可能不便于基于断言的程序设计并且需要一个变量来保存查询结果： 
Iterator iterator = collection.iterator();
while(iterator.hasNext();){
Object current = iterator.next();
... use current...
}

 
下面，我们考虑接口设计的第二个原则：

组合方法（Combined Method） 
组合方法经常在线程和分布环境中使用，来保证正确性并改善效率。

一些接口提供大量的方法，起初，这些方法看来是最小化的，而且相关性强。然而，在使用的过程中，一些接口显现得过于原始，它们过于简单化，从而迫使类用户用更多的工作来实现普通的任务，并且，方法之间的先后顺序及依赖性比较强（即，暂时耦合）。这导致了代码重复，而且非常麻烦和容易出错。

一些需要同时执行成功的方法，在多线程、异常、和分布的情况下会遇到麻烦。如果两个动作需要同时执行，它们由两个独立的方法进行描述，必须都完全成功的执行，否则会导致所有动作的回滚。

线程的引入使这种不确定性大大增加。一系列方法同时调用一个易变的(mutable)对象，如果这个对象在线程之间共享，即使我们假设单独的方法是线程安全的，也无法确保结果是意料之中的。看下面对Event Source的接口，它允许安置句柄和对事件的查询： 
interface EventSource{
Handler getHandler(Event event);
void installHandler(Event event, Handler newHandler);
}

 


线程之间的交叉调用可能会引起意想不到的结果。假设source域引用一个线程共享的对象，对象很可能在1、2之间被另一个线程安装了一个新的句柄： 
class EventSourceExample{
public void example(Event event, Handler newHandler){
oldHandler = eventSource.getHandler(event);    // 1
//对象很可能在这里被另一个线程安装了一个新的句柄
eventSource.installHandler(event, newHandler);  // 2
}
private EventSource eventSource;
private Handler oldHandler;
}

 


为了解决问题，也需要由类的使用者而不是类的设计者来完成： 
class EventSourceExample{
public void example(Event event, Handler newHandler){
synchronized(eventSource){
oldHandler = eventSource.getHandler(event);
eventSource.installHandler(event, newHandler);
}
}
private EventSource eventSource;
private Handler oldHandler;
}

 


我们假设：目标对象eventSource是远程的，执行每一个方法体的时间和通讯的延迟相比是很短的。在这个例子中，eventSource的方法被调用了两次，并可能在其他的实例中重复多次，因而，开销也是至少两倍。

此外还有一个问题是对外部的synchronized同步块的使用需求。对synchronized块的使用之所以会失败，主要因为我们通过代理对象来完成工作，所以，调用者的synchronized块，同步的是代理对象而不是最终的目标对象，调用者不可能对其行为做太多的保证。

Combined Method必须在分布的环境，或者，线程环境中同时执行。它反映了用户直接的应用，恢复策略和一些笨拙的方法被封装到Combined Method中，并简化了接口，减少了接口中不需要的累赘。Combined Method的效果是支持一种更像事务处理风格的设计。

在一个组合的Command-Query中提供一个单独的Query方法通常是合理的。提供分离的Command方法是不太常见的，因为Combined Method可以完成这一工作，只要调用者简单的忽略返回结果。如果返回一个结果招致一个开销的话，才可能会提供一个单独的Command方法。

回到前一个例子中，如果installHandler method返回上一次安装的句柄，则设计变得更加简单和独立： 
interface EventSource{
Handler installHandler(Event event, Handler newHandler);
}

 


客户代码如下：
class EventSourceExample{
public void example(Event event, Handler newHandler){
oldHandler = eventSource.installHandler(event, newHandler);
}
private EventSource eventSource;
private Handler oldHandler;
}
 


这样，我们给调用者提供了一个更加安全的接口，并且不再需要他们解决线程的问题。从而降低了风险和代码量，将类设计的职责全部给了类设计者而不是推给用户，即使有代理对象的出现也不会影响到正确性。

一个Combined Method可以是许多Query的集合，许多Command的集合，或者两者兼有。这样，它可能补充Command、Query方法，也可能与之相抵触。当冲突发生的时候，优先选择Combined Method会产生一个不同的正确性和适用性。

在另一个例子中，我们考虑获得资源的情况。假设，在下面的接口中，方法acquire在资源可用前阻塞： 
interface Resource{
boolean isAcquired();
void acquire();
void release();
}
 


类似于下面的代码会在一个线程系统中推荐使用： 
class ResourceExample{
public void example(){
boolean acquired = false;
synchronized(resource){
if(!resource.isAcquired())
resource.acquire();
else
acquired = true;
}
if(!acquired)
...
}
private Resource resource;
}
 


然而，即使我们放弃可读性和易用性，这样的设计也不是一个Command-Query分离的设计。如果引入了代理，它就会失败： 
class ActualResource implements Resource {...}
class ResourceProxy implements Resource {...}

 


如果用户既可以通过ActualResource来完成工作，也可以通过ResourceProxy来完成工作，而且，ActualResource和ResourceProxy都没有处理同步，则synchronized块可能会失败。因为，既然我们可以通过代理对象ResourceProxy来完成工作，那么，调用者的synchronized块，同步的就是代理对象ResourceProxy而不是最终的目标对象ActualResource。

一个Combined Method解决了这个问题，它使并发和间接性更加透明。
interface Resource{
boolean tryAcquire();
}

下面的代码清晰、简单并且正确： 
class ResourceExample{
public void example(){
if(!resource.tryAcquire())
...
}
private Resource resource;
}

 
Combined Method带来的一个结果是使一些测试和基于断言的程序设计变得十分笨拙，然而，它适合解决线程和分布问题。

实际应用中，接口应该单一化还是复合化，要视具体情况而定。