空(标识)接口的重要性

　　这是昨天我跟天意在一次闲聊中一次有起的讨论，标签接口真有那么重要吗？比如说很多初学者认为java.io.Serializable这样的接口，很多时候可用可不用，不用一样能执行对象系列化功能。
　　为此，我们通过一个通俗而有趣的示例！这个示例是设计一个猎人，其持有一把智能猎枪，这就是说这把猎枪会自动识别人类，若发现瞄准的目标是人类，就不会开火，而其它的任何事物都通杀。
　　为此，我们使用了下面三个接口：
　　一个用来表示万事万物的SomeThing
　　　　
　　public interface SomeThing {}　　

　　人类的接口：
　　public interface Humans extends SomeThing {}

　　动物的接口：
public interface Animals extends SomeThing {}

然后是一系列的实现：
   中国人：     
public class Chinese implements Humans {}

   日本人：
public class Japanese {}

   狗：
public class Dog implements Animals {}

妖怪(他很聪明,给自己帖上了人的标签)：
public class Monster implements Humans {}

下面这个程序的核心部分，猎人类及客户端程序：
public class Hunter {
public void fire(Object target)
{
 if(target instanceof Humans)
 {
  System.out.println("这下完了，打中了一个人，该去坐牢了！");
 }
 else
 {
  System.out.println("恭喜你，打中了一只动物!");
 }
}
//智能的枪
public void intelligentFire(Object target)
{
 if(target instanceof Humans)
 {
  return;
 }
 System.out.println("开了一枪!"+target.getClass());
 //下面进行秒杀等相关处理
 //销毁他
 target=null;
}
public static void main(String[] args) {
Hunter hunter=new Hunter();
Object[] objects=new Object[]{new Dog(),new Japanese(),new Japanese(),new Chinese(),new Monster(),new SomeThing(){}};
for(int i=0;i<objects.length;i++)
 hunter.intelligentFire(objects[i]);
}
}

 运行程序，你会发现输出类似下面结果：

开了一枪!class springroad.demo.taginterface.Dog
开了一枪!class springroad.demo.taginterface.Japanese
开了一枪!class springroad.demo.taginterface.Japanese
开了一枪!class springroad.demo.taginterface.Hunter$1

　　由此可见，智能猎枪瞄准6个目标，开了4枪。只对Chinese、及Monster的实例没有开枪。因为这里讨论的是标签接口，虽然Humans没有任何方法，但从智能猎枪的角度来看，他就是通过这个标签来判断是否可以开火的。他不用管也管不了目标的层次等级关系（比如Japanese肯定很非常鲜明等级结构)，即继承关系。他也管不了目标的来自于哪儿。比如，是用new操作符创建，还是从容器中取，或者是从网络某个地方加载一个。
　　Hunter只是制订了一个简单的规则，你要想不让我的枪对你开火，你就必须在自己身上帖上一个Humans的标签。也就是说你必须遵守这个规则。
　　现在回过头来看，因为妖怪Monster真身应该是一条蛇或其它什么动物，但是他懂得Hunter制订的规则，于在巧妙的给自己帖上了一个Humans的标签，以致于欺骗了我们的智能猎枪。
　　而Japanese则自认为自己了不起，不按规则办事，我就不理你Hunter制订的规则，什么Humans标签，我就是不用。于是放到我们的程序中当然就只有挨杀的份了。

　　由此可见，空接口(标签接口)的重要性，在像本例中，给不给自己帖不标签，这是一个性命莜关的问题。其实在OO的世界中，空接口可以算是最高的层像。
　　
　　相关文章：《也谈接口编程》

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1353117