设计模式之类02--多用组合少用继承

为什么不推荐使用继承？
比如鸟, 有会飞的,不会飞的. 会叫的,不会叫的，如果用继承, 类的继承层次会越来越深、继承关系会越来越复杂。
一方面，会导致代码的可读性变差。因为我们要搞清楚某个类具有哪些方法、属性，必须阅读父类的代码、父类的父类的代码……一直追溯到最顶层父类的代码。
另一方面，这也破坏了类的封装特性，将父类的实现细节暴露给了子类。子类的实现依赖父类
的实现，两者高度耦合，一旦父类代码修改，就会影响所有子类的逻辑

组合相比继承有哪些优势？
实际上，我们可以利用组合（composition）、接口、委托（delegation）三个技术手段，一块儿来解决刚刚继承存在的问题

实现了fly()方法的FlyAbility类、实现了tweet()方法的TweetAbility类、实现了layEgg()方法的EggLayAbility类

public interface Flyable {
	void fly();
}
 public interface Tweetable {
	void tweet();
}
 public interface EggLayable {
	void layEgg();
} 

public interface Flyable {
	void fly()；
} 
public class FlyAbility implements Flyable {
@Override
	public void fly() { //... }
} /
/省略Tweetable/TweetAbility/EggLayable/EggLayAbility

public class Ostrich implements Tweetable, EggLayable {//鸵鸟
	private TweetAbility tweetAbility = new TweetAbility(); //组合
	private EggLayAbility eggLayAbility = new EggLayAbility(); //组合
	//... 省略其他属性和方法...
	@Override
	public void tweet() {
		tweetAbility.tweet(); // 委托
	} 
	@Override
	public void layEgg() {
		eggLayAbility.layEgg(); // 委托
	}
}

如何判断该用组合还是继承？
尽管我们鼓励多用组合少用继承，但组合也并不是完美的，继承也并非一无是处。在实际的项目开发中，我们还是要根据具体的情况，来选择该用继承还是组合

1. 如果类之间的继承结构稳定（不会轻易改变），继承层次比较浅（比如，最多有两层继承关系），继承关系不复杂，我们就可以大胆地使用继承。
2. 反之，系统越不稳定，继承层次很深，继承关系复杂，我们就尽量使用组合来替代继承。