接口与抽象超类
接口和抽象超类以前都有用过，当时就有点疑惑，明明接口的这个功能有超类来替代就是可以的，何必还要有接口这个东西呢，今天看了《JAVA 与模式》中的阐述才算明白。
之所以要用接口来实现软件的可插入性，是因为如果我们选择基于类的继承来保证可插入性，应该说在最简单的情况下可以实现，但是如果当一个类要同时实现两种接口的时候，用类的继承实现方式就出现了问题，因为在C#中还是JAVA中，一个类只能继承自一个超类，而可以实现多个接口。所以要用类的继承实现方式保证可插入性就必须出现一个超超类，这样就违反了Open Close Principle。所以说这也就是什么时候采用接口继承、什么时候采用类继承的主要参考原则。
而且，在下列情况用接口来保证可插入性显得更灵活，（关联可插入性）如一个对象要完成一个任务要知道另外一个对象并调用其方法，这个对象对其他对象的知识叫关联，而这个关联可以移到与接口，即是关心的不是具体类，而是具体类有没有实现该接口。（调用可插入性）由调用具体类变成了通过接口调用具体类，这样在调用的时候就不必关心具体类，而是动态决定，只要实现该接口的类都可以被调用。
前段时间公司培训，有一位讲师在讲述面向对象的过程中讲到，曾经有人建议过让他们编码的时候尽量的花点时间把接口抽象出来，然后再去实现它，后来遭到他们的反对，所以也就没有执行。而现在系统做的越来越大了，由具体类之间的依赖所引发的问题也应该就越来越多了，处理起来也越来越棘手了，所以可以说软件越复杂，规模越大，客制化越多，接口的重要性就越大。
以前学J2EE的时候觉得J2EE里面无论是EJB， 还是Servelet、Jsp,JMS怎么就那么多接口呢，看来是自己愚昧了
之所以要用接口来实现软件的可插入性，是因为如果我们选择基于类的继承来保证可插入性，应该说在最简单的情况下可以实现，但是如果当一个类要同时实现两种接口的时候，用类的继承实现方式就出现了问题，因为在C#中还是JAVA中，一个类只能继承自一个超类，而可以实现多个接口。所以要用类的继承实现方式保证可插入性就必须出现一个超超类，这样就违反了Open Close Principle。所以说这也就是什么时候采用接口继承、什么时候采用类继承的主要参考原则。
而且，在下列情况用接口来保证可插入性显得更灵活，（关联可插入性）如一个对象要完成一个任务要知道另外一个对象并调用其方法，这个对象对其他对象的知识叫关联，而这个关联可以移到与接口，即是关心的不是具体类，而是具体类有没有实现该接口。（调用可插入性）由调用具体类变成了通过接口调用具体类，这样在调用的时候就不必关心具体类，而是动态决定，只要实现该接口的类都可以被调用。
前段时间公司培训，有一位讲师在讲述面向对象的过程中讲到，曾经有人建议过让他们编码的时候尽量的花点时间把接口抽象出来，然后再去实现它，后来遭到他们的反对，所以也就没有执行。而现在系统做的越来越大了，由具体类之间的依赖所引发的问题也应该就越来越多了，处理起来也越来越棘手了，所以可以说软件越复杂，规模越大，客制化越多，接口的重要性就越大。
以前学J2EE的时候觉得J2EE里面无论是EJB， 还是Servelet、Jsp,JMS怎么就那么多接口呢，看来是自己愚昧了
