结合实际项目讲解接口的作用

Question

java项目的经验不是很多，虽然这几年一直关注，但始终不理解接口的作用，大家能否举个项目中的例子来阐述必须用接口，或者不用接口就特别麻烦？
我也搜了论坛里的其他帖子，如以下的回复↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
 interface   test{   
    void   go();   
  }   
    
  class   testaaa   implements   test{   
  public   void   go()   
  {   
      System.out.println("exe");   
  }   
  }   
  -------------------   
  class   TestFactory   {   
  ...   
  public   test   getTest(){   
  ....   
  return   testaaa;   
  }   
      
  }   
  --------------------------------------   
    
  example.java   
  test   t   =   TestFactory.getTest();   
  t.go();   
    
  如果testaaa发声变化或者给作者修改，对于这部分代码，可能永远都不需要修改。   
  甚至可以不必知道有testaaa这个东东的存在。   
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑比如我写可能就是class   testaaa   {   
  public   void   go()   
  {   
      System.out.println("exe");   
  }   
testaaa   t   =   new testaaa 
t.go();   这样写有什么不妥吗？如果有什么变化也就是修改这个类testaaa，和上面例子中修改的地方一样，我觉得这么写简单，清晰。至于testaaa 的go是怎么写的，我也不需要考虑那么多，拿来用不就可以了吗？

Answer 1

如果你的test接口是你们一个项目开发团队统一定义的，而你的testaaa类中的go()方法是给开发其他模块的很多同事调用的，那么他们不需要知道你的类叫做testaaa还是别的什么，他们只需要确保你的类实现了test接口即可，因为只要实现了test接口就必定实现了go()方法。将来你可能由于某种原因，不用testaaa做为类名了，调用了你的testaaa类中的go()方法的同事也不需要对他们的代码做任何修改。接口test在这里起解耦的作用，使得你和你的调用者之间可以相对独立地进行开发。

Answer 2

>>而你的testaaa类中的go()方法是给开发其他模块的很多同事调用的，那么他们不需要知道你的类叫做testaaa还是别的什么
针对这个，完全可以事先定义一个类，内容可以随意，以供大家用，而且这样的类几乎都是先开发的吧。
所以不会存在你说的这种情况，或者说就为了解决这种问题弄出一个接口吗？
>>将来你可能由于某种原因，不用testaaa做为类名了，调用了你的testaaa类中的go()方法的同事也不需要对他们的代码做任何修改。接口test在这里起解耦的作用，使得你和你…
有这种情况吗？类名还需要改？真的，我只碰到过重做的项目，这样共通的类几乎没有重做的。

Answer 3

那如果要实现go()方法的类不止你testaaa一个，而是有很多个，并且是由不同的人编写的呢？？你也能把它们都“事先定义”出来并保持不变吗？当然，你会说，这种特征用继承也可以实现啊？干吗要用接口？这似乎又要回到“用接口来解决多继承”这个令人不快的话题上了。就是说，你可能有自己的继承关系树，导致你的类已经继承自某个基类了，这时你就无法再继承那个“公共的类”。如果那个“公共的”不是一个类，而是一个接口，你就有了更多的灵活性。类名需不需要改？至少在软件重构过程中这种需求是非常多的。这个暂且不说。请问，作为一个大的软件开发团队中的一员，你是希望你的代码暴露的越多越好，还是越少越好？当然是越少越好，因为这样就意味着你的同事对你的代码的依赖性越小，也越便于你自如地组织你的内部结构。private成员可以隐藏在类中，而工厂模式和接口则更进一步，让你的类隐藏在工厂中，仅将接口暴露给使用者。现在，你就不仅可以在一个类的内部进行结构重整，更可以在工厂内进行大幅的调整，而不影响工厂的使用者。现在来说说为类“改名”的情况。举例说，游戏中有很多个角色，它们已经在现有版本中正常工作很久了。现在，有些角色需要升级为第二代，比如“角色A”，现在升级为“角色A第二代”。原有的角色A仍需保留，所以不能直接修改角色A，而必须用新的类对角色A进行扩展。同时，“角色A第二代”为新版本的默认角色，取代角色A。现在，你必须通知所有调用了角色A的程序员：“角色A升级了，修改你们代码中所有的角色A为角色A第二代”。你能想象这种情况吗？这就是“为类改名”，呵呵。同样是上面的例子，如果用工厂来实现则可以避免这种灾难性的后果。你只需要在工厂中加入新的类，并且把原来返回角色A实例的地方改为返回角色A第二代，再加入一个选项，让用户可以选择性地获取旧版本的角色A即可。

Answer 4

回上面帖子的时候没看到你的回复>>那如果要实现go()方法的类不止你testaaa一个，而是有很多个，并且是由不同的人编写的呢？？你也能把它们都“事先定义”出来并保持不变吗？ 
 
既然有不同的go（），每个go（）也就没有什么共性了，要我做也就不把它作为一个公共类了，大伙自己写自己的类和自己的方法呗？
像你说的难道这个时候用接口就方便吗？
【接口名】 【对象名】=new 【实现接口的类】 
说到底还点指定到我的类，
用到接口的时候不也是点指定到我自己的类上？按你这么解释，用了接口感觉无非就是统一个方法名称而已。难道就为了这个规范？
层次的人干活的时候，开发人员去实现，<<请问，作为一个大的软件开发团队中的一员，你是希望你的代码暴露的越多越好，还是越少越好？当然是越少越好，因为这样就意味着你的同事对你的代码的<<依赖性越小，也越便于你自如地组织你的内部结构。private成员可以隐藏在类中，而工厂模式和接口则更进一步，让你的类隐藏在工厂中，仅将接口暴露给<<使用者。现在，你就不仅可以在一个类的内部进行结构重整，更可以在工厂内进行大幅的调整，而不影响工厂的使用者。 
没能理解你说的，我估计可能就是因为我没理解你的话所以才搞不懂接口的作用，如果你能看到这个回复，再辛苦多打几个字，谢了。
1、代码暴露
   这个该怎么理解呢？我那么做怎么就暴露了呢？
   对于依赖性，其实我的想法很简单，能够共通的东西就做成共同的类，大家直接调用就OK，我把功能，参数，返回值什么的告诉你，你拿过去用就行。<<关于你提到的游戏角色
恩，结合你的列子，能够理解了。不过单单就这个例子而言，既然游戏角色升级而且还要保存升级前和升级后的，那么也不需要继承出来一个新的类，修改原来的类也应该能实现，也就是一个类里包含两个版本的角色信息。