关于设计模式:head-first-设计模式-U1

8次阅读

共计 1379 个字符,预计需要花费 4 分钟才能阅读完成。

1.0 版本:初始实现
duck 类有 quack,swin,display 办法
mallardduck 和 redheadduck 继承 duck 类并改写 display 办法

需要:减少会飞的鸭子
1.1 版本:继承
解决的操作:duck 减少 fly 办法
-> 问题:橡皮鸭子不会飞,然而继承了 fly 办法,所以会飞了
-> 解决的操作:橡皮鸭子笼罩 fly 办法重写为空办法
->
问题 1:橡皮鸭子不会飞然而有 fly 办法,容易引起误会
问题 2:退出其余类型鸭子,不同的行为都须要重写代码,比方说木头假鸭,不会飞也不会叫,须要重写 quack 和 fly 办法为空
毛病:代码反复,运行时行为不能扭转,很难晓得鸭子的真正行为,改一发而动全身

2.0 版本:接口
解决:
1.duck 类去除 fly 和 quack 办法,减少 flyable 接口和 quackable 接口
2. 所有鸭子继承自 duck 类,且实现了 flyable 接口和 quackable 接口
毛病:
1. 代码反复,无奈复用。所有鸭子类型都要写本人的 fly 和 quack 办法。
2. 改一发而动全身。只有批改了某种 fly 办法,就要批改雷同实现的所有鸭子类型。

3.0 版本:策略模式
设计准则:找出利用中可能须要变动之处,把它们独立进去,不要和那些不须要变动的代码混在一起。即,把会变动的局部取出并封装起来,以便当前能够轻易的改变或裁减此局部,而不影响不须要变动的其余局部。
解决的问题:把会变动的局部封装起来,改变时好让其余中央不会受到影响

设计准则:针对接口编程,而不是针对实现编程。即,将特定的具体行为编写在了接口中。
解决的问题:没有方法扭转对象行为

针对接口编程的真正意思是针对超类型编程。形象超类型能够是抽象类或接口
很好的例子:
针对实现编程:
dog d = new dog()
d.bark()
针对接口 / 超类型变成:
animal animal = new dog();
animal.makeSound() // 子类 dog 的 makeSound 调用 bark 办法
优化:子类实现的动作不须要硬编码,能够在运行时才指定具体实现的对象
a = getAnimal()
a.makeSound()

设计准则:多用组合,少用继承
当你把两个类联合起来应用,就是组合
应用组合建设零碎具备很大的弹性,不仅能够将算法族封装成类,更能够在运行时动静的扭转行为,只有组合的行为对象合乎正确的接口标准即可。

实现:duck 抽象类,flybehavior 接口,quackbehavior 接口
行为类 flywithwings,flynoway 实现 flybehavior 接口(策略模式)
行为类 quack,squeak,mutequack 实现 quackbehavior 接口(策略模式)
duck 类中有两个实例变量 flybehavior 和 quackbehavior,申明为接口类型
duck 类中应用 performQuack 代替 quack 办法委托给 quackbehavior 实例,performFly 代替 fly 办法委托给 flybehavior 实例
duck 类中退出 setflybehavior 和 setquackbehavior 办法,能够在运行时调用以动静扭转鸭子行为

总结:
oo 根底:形象,封装,多态,继承
oo 准则:封装变动,多用组合少用继承,针对接口编程而不是实现
oo 模式:策略模式:定义算法族,别离封装起来,让它们之间能够相互替换,此模式让算法的变动独立于应用算法的客户

正文完
 0