设计模式学习笔记 - 1 - 策略模式

开始:

我们使用继承来达到代码重用的问题,只要在超类中定义新的方法,那么所有的子类都将拥有新的方法和这一方法带来的特征。

 

 


 

 

问题一:

如果我们改变超类,那么所有的子类都会改变,导致不应该变的子类也随之变化了,这导致了新的麻烦“牵一发而动全身”

 

设计原则一:

找出应用中可能变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起。

 

 


 

 

问题二:

我们把会变化的部分提取出来以后,我们抽象出一些功能,为这些功能定义了接口,然后用子类去实现接口。但是我们发现,如果有很多需要改变的子类,一个一个实现接口并没有减轻我们的工作量。这和在每个需要改变的类中去覆盖超类的方法,没有多大的区别。我们从一个火坑跳到了另一个火坑中。

 

设计原则二:

针对接口编程,而不是针对实现编程。

* 把相似的功能作为接口,然后用不同的功能类但相似的类去实现接口。用我们原本想要改变的子类去使用这些已经实现功能类。就可以在运行时通过实现接口的类,来绑定不同的功能。

 

 


 

现在我们可以实现一个比较好的鸭子的设计模式了。

这里的代码来自 《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!

 

 

 


 

 

问题三:

一开始我们是静态绑定行为的,但是我们可以在运行时改变行为吗?

 

原则三:

多用组合,少用继承

* 组合可以使系统有更大的弹性,不经可以将算法簇封装成类,更可以“在运行时动态改变行为”

 

 


 

 

至此我们,我们学会了第一个设计模式

 

策略模式

 

定义了算法簇,分别封装起来,让他们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值