接口和 继承方式之比较的漫谈

当使用继承的时候，主要是为了不必重新开发，并且在不必了解实现细节的情况下拥有了父类我所需要的特征。

但是很多时候，一个子类并不需要父类的所有特征，它可能只是需要其中的某些特征，但是由于通过继承，父类所有的特征都有了，需要的和不需要的特征同时具备了。而那些子类实际上不需要用到的，有时候甚至是极力避免使用的特征也可以随便使用，这就是继承的副作用。特别是允许多重继承的OO语言中，很容易引起不容易发现的错误。所以在OO的语言中，会创造出各种规定来限制子类使用父类中的某些方法。

就拿你举的例子来说，如果狗的主人只是希望狗能爬比较低的树，但是不希望它尾巴可以倒挂在树上，像猴子那样可以飞檐走壁，以免主人管不住它。那么狗的主人肯定不会要一只猴子继承的狗。

设计模式更多的强调面向接口。猴子有两个接口，一个是爬树，一个是尾巴倒挂。我现在只需要我的狗爬树，但是不要它尾巴倒挂，那么我只要我的狗实现爬树的接口就行了。同时不会带来像继承猴子来带来的尾巴倒挂的副作用。这就是接口的好处。

OO技术发展也有好多年了，一个很明显的趋势就是继承的使用越来越少，而接口的使用越来越广泛了。其实只要稍微比较一下JDK里面那些最早就有的类库和最近才加进去的类库，就可以很明显的感觉到OO技术领域的编程风格的变迁，由大量的继承到几乎无处不用的面向接口编程。

呵呵，接口不是替代继承。比如说我现在就是要我的动物去爬树，我根本就不需要知道到底是狗去爬树还是猴子去爬树。我派一个“能爬树”的动物去爬。这个能爬树的动物既可以是猴子，也可以是狗。这样不是很灵活吗？

狗（爬树，咬人）
猴子（爬树，尾巴倒挂）

如果我只要满足爬树的要求，我根本就不管它是不是狗。

如果我既要爬树也要咬人，那么我当然可以选狗，也可以创建一个接口（爬树咬人），然后让狗实现（爬树咬人）接口。

因为我要的是实现我的软件的功能，只要实现了我需求的功能，我管它是不是狗呢？也许狗可以，也许狗不可以，也许狗今天可以，以后又不可以了。我都不管。我只要（爬树咬人）接口。

也许我原来一直用狗来完成我的爬树咬人接口，但是后来我发现另一种动物，比如猫吧，在爬树咬人这个功能上比狗更灵活，于是我就用猫替换了狗，而且代码一点都不需要修改。

因为我很可能要在另一个继承的子类里面使用这些方法，所以我不能在父类里面定义为private的，否则为了在某个子类中屏蔽，所有的其它子类都不能用了，这不是我想要的。


我觉得现在应该称为面向接口编程更加合适一点。

其实过度的强调面向接口编程。很容易出现很多小接口（或许理解为功能比较单一的接口）比如：
狗（爬树，咬人）
猴子（爬树，尾巴倒挂）

那是不是设计3个接口？通常情况下肯定是。
当出现第三种动物猫（爬树，捉老鼠）是不是考虑加一个接口？捉老鼠？

有何不可？

把接口当函数指针理解也行啊

按我的理解，指针也好，接口也好，应该是一张表的入口。接口对应的那张表，名字与变量是还没绑定的
继承则是在父表的基础上增加一个子表，描述扩充信息。
两者在灵活性上的差别就出来了。
我觉得这些东西还是应该从低层的角度来理解，用抽象描述去解释抽象概念，只会越说越不清楚。

p.s:
     这是我自己的瞎猜，说错了请帮忙纠正一下。：）
很想了解Java的对象模型，不知在Java这边有没有与<<深度探索C++对象模型>>对应的书?我发现Java这边此类书籍极少，铺天盖地的都是EJB:(

没有这个类书，因为C++非常复杂，而Java非常简单，对象概念很清楚，没有什么特别复杂的地方，一本《Thinking in Java》已足够。

从逻辑上来说，抽象类适合继承，就是is a 关系。
如果A从构造上讲属于B，那么就是A is a B。
这种情况用抽象类较合适。
如果C具有D的功能，但构造上不属于D，就是has a 功能，C has a D
当然这里的is a 和has a  和面对对象中的原教旨不同，并且两者的区分并不是绝对的，一切都要取决于系统中的合适的定位，包括类的内涵的定位。如果定位准，出现前后和意义上矛盾的可能性就比较少。
一点意见，欢迎指教。

:lol:  

其实面向对象本身并不是非常复杂，这样它才适合完成无限层次的封装，如果低层的技术都非常复杂了，大的软件开发起来就很困难了。
C++ 不是纯面向对象的语言，而且还把面向对象给复杂化了。我觉得 Java 是学习面向对象最好的语言。另外还有 Delphi 和 Python，可能还有 C#。
面向对象的基本思想包括：
接口、继承、组合、向上造型、向下造型、动态联编、运行时类型标识、重载、覆盖。
Java 对象模型是单根模型，所有对象的父类都是 Object 类。这是与 C++ 最大的区别。
我这里有 TIJ 第 3 版中文版（pdf 格式），要的话发给你。