开始:
我们使用继承来达到代码重用的问题,只要在超类中定义新的方法,那么所有的子类都将拥有新的方法和这一方法带来的特征。
问题一:
如果我们改变超类,那么所有的子类都会改变,导致不应该变的子类也随之变化了,这导致了新的麻烦“牵一发而动全身”
设计原则一:
找出应用中可能变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起。
问题二:
我们把会变化的部分提取出来以后,我们抽象出一些功能,为这些功能定义了接口,然后用子类去实现接口。但是我们发现,如果有很多需要改变的子类,一个一个实现接口并没有减轻我们的工作量。这和在每个需要改变的类中去覆盖超类的方法,没有多大的区别。我们从一个火坑跳到了另一个火坑中。
设计原则二:
针对接口编程,而不是针对实现编程。
* 把相似的功能作为接口,然后用不同的功能类但相似的类去实现接口。用我们原本想要改变的子类去使用这些已经实现功能类。就可以在运行时通过实现接口的类,来绑定不同的功能。
现在我们可以实现一个比较好的鸭子的设计模式了。
这里的代码来自 《Head First 设计模式》
1. 首先我们定义超类Duck
2. 然后我们定义飞行行为的接口
3. 我们实现飞行行为的类
能飞的
和不能飞的
4.同样我们定义叫呱呱叫行为的接口
5. 同样我们实现呱呱叫的类
呱呱叫的
吱吱叫
不会叫的
6. 使用超类和接口实现具体的绿头鸭类
7.完成演示程序
8.运行结果
Quack
I'm flying!
我们看到我们在绿头鸭的类中实例化了quackBehavior和flyBehavior,这种实现是静态的。
现在我们可以把这红实现改为动态的,以便于在运行中修改鸭子的行为。
1. 在Duck类中,两个新方法
2.建立一个新的鸭子类型模型鸭
3. 实现新的火箭飞行类型
4. 修改演示程序
5.运行结果
Quack
I'm flying!
I can't fly
I'm flying with a roket!
问题三:
一开始我们是静态绑定行为的,但是我们可以在运行时改变行为吗?
原则三:
多用组合,少用继承
* 组合可以使系统有更大的弹性,不经可以将算法簇封装成类,更可以“在运行时动态改变行为”
至此我们,我们学会了第一个设计模式
策略模式
定义了算法簇,分别封装起来,让他们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。