headfast设计模式学习笔记01
2015-03-31 18:13
253 查看
不管开始软件设计的多好,一段时间后就需要改变。
架构会随着业务的改变而需要不断优化
第一步使用继承。继承的缺陷:行为会随子类不断改变,所有子类都有这些行为是不恰当的。不断的去重写覆盖父类的方法不恰当。
第二步使用接口。将fly()放进Flyable接口,只有会飞的鸭子实现Flyable接口。缺陷,不用覆盖,但是反过来每个会飞的子类都要去实现Flyable接口,修改fly(),重复代码更多。
发现目的:一种软件设计方法,对现有代码改动小,花少的时间重做代码。
引出第一个原则:找出应用中可能需要变化之处,独立(封装)起来,不要和那些不需要变化的代码混在一起。
把鸭子的飞行和叫抽出来,可以动态指定鸭子的行为,即类中提供该行为的接口的实现。
引出第二个原则:针对接口编程,而不是针对实现编程。
以前的将行为是由父类实现或者子类自行实现,这些都是依赖于实现。现在将飞行独立为接口,并每个不同的飞行类对接口进行不同的实现。
结果:1、不同的飞行动作可以被其他对象复用,新增一些行为时,不会影响到已经有的行为类。
2、在设计系统时,预先考虑到未来可能需要变化的地方,加入这些弹性。
3、类不仅可以抽象一个实体东西,也可以抽象行为,因为即使是行为也可以有状态和方法。
另一个列子:有一个CustomTextField需要验证,然后就有一个InputValidator(验证的基类)以及一系列验证的子类, AlphaInputValidator, NumericInputValidator...
引入第三个设计原则:多用“组合”少用“继承”;
“有一个”xx行为可能比“是一个”xx行为更好
将两个类结合结合起来使用,就是组合。即鸭子的行为不是继承来的,而是和适当的行为对象“组合”来的。
总结概念:策略模式中的一个关键角色是策略类,它为所有支持或者相关的算法声明了一个共同接口,另外还有使用策略接口来实现相关算法的具体策略类。场景类的对象配置有一个具体策略对象的实例,场景对象使用策略接口调用为具体策略类定义的算法。
何时使用:1一个类在其操作中使用多个条件语句来定义许多行为,可以把相关条件分支移到自己的策略类中。
2需要算法的各种变体
3避免把重复的,与算法相关的数据结构暴露给客户端。
策略模式的优点:
1.提供了管理相关算法族的方法。
2.可以避免使用多重条件转移语句。
缺点:
3.必须知道所有的具体策略类及它们的区别.
4.生成许多的策略类。
架构会随着业务的改变而需要不断优化
第一步使用继承。继承的缺陷:行为会随子类不断改变,所有子类都有这些行为是不恰当的。不断的去重写覆盖父类的方法不恰当。
第二步使用接口。将fly()放进Flyable接口,只有会飞的鸭子实现Flyable接口。缺陷,不用覆盖,但是反过来每个会飞的子类都要去实现Flyable接口,修改fly(),重复代码更多。
发现目的:一种软件设计方法,对现有代码改动小,花少的时间重做代码。
引出第一个原则:找出应用中可能需要变化之处,独立(封装)起来,不要和那些不需要变化的代码混在一起。
把鸭子的飞行和叫抽出来,可以动态指定鸭子的行为,即类中提供该行为的接口的实现。
引出第二个原则:针对接口编程,而不是针对实现编程。
以前的将行为是由父类实现或者子类自行实现,这些都是依赖于实现。现在将飞行独立为接口,并每个不同的飞行类对接口进行不同的实现。
结果:1、不同的飞行动作可以被其他对象复用,新增一些行为时,不会影响到已经有的行为类。
2、在设计系统时,预先考虑到未来可能需要变化的地方,加入这些弹性。
3、类不仅可以抽象一个实体东西,也可以抽象行为,因为即使是行为也可以有状态和方法。
另一个列子:有一个CustomTextField需要验证,然后就有一个InputValidator(验证的基类)以及一系列验证的子类, AlphaInputValidator, NumericInputValidator...
引入第三个设计原则:多用“组合”少用“继承”;
“有一个”xx行为可能比“是一个”xx行为更好
将两个类结合结合起来使用,就是组合。即鸭子的行为不是继承来的,而是和适当的行为对象“组合”来的。
总结概念:策略模式中的一个关键角色是策略类,它为所有支持或者相关的算法声明了一个共同接口,另外还有使用策略接口来实现相关算法的具体策略类。场景类的对象配置有一个具体策略对象的实例,场景对象使用策略接口调用为具体策略类定义的算法。
何时使用:1一个类在其操作中使用多个条件语句来定义许多行为,可以把相关条件分支移到自己的策略类中。
2需要算法的各种变体
3避免把重复的,与算法相关的数据结构暴露给客户端。
策略模式的优点:
1.提供了管理相关算法族的方法。
2.可以避免使用多重条件转移语句。
缺点:
3.必须知道所有的具体策略类及它们的区别.
4.生成许多的策略类。
相关文章推荐
- headfast设计模式学习笔记02 装饰者
- 【Head-First设计模式】C#版-学习笔记-开篇及文章目录
- 《设计模式:基于C#的工程化实现及扩展》学习笔记 01 准备篇 -- 前言
- 设计模式学习笔记01
- HeadFir st 设计模式学习笔记11——状态模式
- HeadFir st 设计模式学习笔记18--中介者(M ediator)模式拾零
- HeadFir st 设计模式学习笔记21-- 解释者(Inter pr eter)模式拾零
- android设计模式学习笔记01
- Head.First设计模式学习笔记
- HeadFir st 设计模式学习笔记22-- 备忘录(M emento)模式拾零
- 设计模式学习笔记01
- C#设计模式(学习笔记[01])
- 设计模式学习笔记--装饰者模式(Decorator Pattern)
- 设计模式C++学习笔记之八(Adapter适配器模式)
- 【设计模式】学习笔记15:代理模式(Proxy Pattern)
- java/android 设计模式学习笔记(10)---建造者模式
- 设计模式学习笔记--构建者模式
- 设计原则(head first 设计模式)学习笔记
- 设计模式学习笔记十六:代理模式(Proxy Pattern)
- C#设计模式学习笔记-单例模式