当使用继承的时候，主要是为了不必重新开发，并且在不必了解实现细节的情况下拥有了父类我所需要的特征。
但是很多时候，一个子类并不需要父类的所有特征，它可能只是需要其中的某些特征，但是由于通过继承，父类所有的特征都有了，需要的和不需要的特征同时具备了。而那些子类实际上不需要用到的，有时候甚至是极力避免使用的特征也可以随便使用，这就是继承的副作用。特别是允许多重继承的OO语言中，很容易引起不容易发现的错误。所以在OO的语言中，会创造出各种规定来限制子类使用父类中的某些方法。
就拿你举的例子来说，如果狗的主人只是希望狗能爬比较低的树，但是不希望它尾巴可以倒挂在树上，像猴子那样可以飞檐走壁，以免主人管不住它。那么狗的主人肯定不会要一只猴子继承的狗。
设计模式更多的强调面向接口。猴子有两个接口，一个是爬树，一个是尾巴倒挂。我现在只需要我的狗爬树，但是不要它尾巴倒挂，那么我只要我的狗实现爬树的接口就行了。同时不会带来像继承猴子来带来的尾巴倒挂的副作用。这就是接口的好处。
OO技术发展也有好多年了，一个很明显的趋势就是继承的使用越来越少，而接口的使用越来越广泛了。其实只要稍微比较一下JDK里面那些最早就有的类库和最近才加进去的类库，就可以很明显的感觉到OO技术领域的编程风格的变迁，由大量的继承到几乎无处不用的面向接口编程。
呵呵，接口不是替代继承。比如说我现在就是要我的动物去爬树，我根本就不需要知道到底是狗去爬树还是猴子去爬树。我派一个“能爬树”的动物去爬。这个能爬树的动物既可以是猴子，也可以是狗。这样不是很灵活吗？
狗（爬树，咬人）
猴子（爬树，尾巴倒挂）
如果我只要满足爬树的要求，我根本就不管它是不是狗。
如果我既要爬树也要咬人，那么我当然可以选狗，也可以创建一个接口（爬树咬人），然后让狗实现（爬树咬人）接口。
因为我要的是实现我的软件的功能，只要实现了我需求的功能，我管它是不是狗呢？也许狗可以，也许狗不可以，也许狗今天可以，以后又不可以了。我都不管。我只要（爬树咬人）接口。
也许我原来一直用狗来完成我的爬树咬人接口，但是后来我发现另一种动物，比如猫吧，在爬树咬人这个功能上比狗更灵活，于是我就用猫替换了狗，而且代码一点都不需要修改。
但是很多时候，一个子类并不需要父类的所有特征，它可能只是需要其中的某些特征，但是由于通过继承，父类所有的特征都有了，需要的和不需要的特征同时具备了。而那些子类实际上不需要用到的，有时候甚至是极力避免使用的特征也可以随便使用，这就是继承的副作用。特别是允许多重继承的OO语言中，很容易引起不容易发现的错误。所以在OO的语言中，会创造出各种规定来限制子类使用父类中的某些方法。
就拿你举的例子来说，如果狗的主人只是希望狗能爬比较低的树，但是不希望它尾巴可以倒挂在树上，像猴子那样可以飞檐走壁，以免主人管不住它。那么狗的主人肯定不会要一只猴子继承的狗。
设计模式更多的强调面向接口。猴子有两个接口，一个是爬树，一个是尾巴倒挂。我现在只需要我的狗爬树，但是不要它尾巴倒挂，那么我只要我的狗实现爬树的接口就行了。同时不会带来像继承猴子来带来的尾巴倒挂的副作用。这就是接口的好处。
OO技术发展也有好多年了，一个很明显的趋势就是继承的使用越来越少，而接口的使用越来越广泛了。其实只要稍微比较一下JDK里面那些最早就有的类库和最近才加进去的类库，就可以很明显的感觉到OO技术领域的编程风格的变迁，由大量的继承到几乎无处不用的面向接口编程。
呵呵，接口不是替代继承。比如说我现在就是要我的动物去爬树，我根本就不需要知道到底是狗去爬树还是猴子去爬树。我派一个“能爬树”的动物去爬。这个能爬树的动物既可以是猴子，也可以是狗。这样不是很灵活吗？
狗（爬树，咬人）
猴子（爬树，尾巴倒挂）
如果我只要满足爬树的要求，我根本就不管它是不是狗。
如果我既要爬树也要咬人，那么我当然可以选狗，也可以创建一个接口（爬树咬人），然后让狗实现（爬树咬人）接口。
因为我要的是实现我的软件的功能，只要实现了我需求的功能，我管它是不是狗呢？也许狗可以，也许狗不可以，也许狗今天可以，以后又不可以了。我都不管。我只要（爬树咬人）接口。
也许我原来一直用狗来完成我的爬树咬人接口，但是后来我发现另一种动物，比如猫吧，在爬树咬人这个功能上比狗更灵活，于是我就用猫替换了狗，而且代码一点都不需要修改。
