随笔:64 文章:1 评论:59 阅读: 47057

随笔分类 -  设计模式

 
15. Command 命令(行为型模式)
摘要:耦合与变化 耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象与实体对象之间存在耦合关系,实体对象与行为操作之间也存在耦合关系。 动机(Motivation) 在软件构建过程中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重做(undo/redo)、事务”等处理,这种无法抵御变化的紧耦合是不合适的。 在这... 阅读全文
posted @ 2008-08-01 19:35 Cameo 阅读(337) 评论(0) 推荐(0) 编辑
14. Template Method模板方法(行为型模式)
摘要:无处不在的Template Method 如果你只想掌握一种设计模式,那么它就是Template Method! 变化——是软件设计的永恒主题,如何管理变化带来的复杂性?设计模式的艺术性和复杂度就在于如何分析,并发现系统中的变化点和稳定点,并使用特定的设计方法来应对这种变化。 动机(Motivation) 在软件构建过程中,对于某一项任务,它常常有稳定的整体操作结构... 阅读全文
posted @ 2008-07-28 19:17 Cameo 阅读(249) 评论(0) 推荐(0) 编辑
13. Proxy代理(结构型模式)
摘要:直接与间接 人们对于复杂的软件系统常常有一种处理手法,即增加一层间接层,从而对系统获得一种更为灵活、满足特定需求的解决方案。 动机(Motivation) 在面向对象系统中,有些对象由于某种原因(比如对象创建的开销很大,或者某些操作需要安全控制,或者需要进程外的访问等),直接访问会给使用者、或者系统结构带来很多麻烦。 如何在不失去透明操作对象的同时来管理... 阅读全文
posted @ 2008-07-25 11:29 Cameo 阅读(236) 评论(0) 推荐(0) 编辑
12. Flyweight享元(结构型模式)
摘要:面向对象的代价 面向对象很好地解决了系统抽象性的问题,同时在大多数情况下,也不会损及系统的性能。但是,在某些特殊的应用中下,由于对象的数量太大,采用面向对象会给系统带来难以承受的内存开销(拆箱操作)。比如图形应用中的图元等对象、字处理应用中的字符对象等。 动机(Motivation) 采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价——主... 阅读全文
posted @ 2008-07-20 10:43 Cameo 阅读(261) 评论(0) 推荐(0) 编辑
11. Facade外观[门面模式](结构型模式)
摘要:意图(Intent) 为子系统中的一组接口提供一个一致的界面,Façade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。 ——《设计模... 阅读全文
posted @ 2008-07-16 11:08 Cameo 阅读(1340) 评论(1) 推荐(0) 编辑
10. Decorator 装饰(结构型模式)
摘要:动机(Motivation) 上述描述的问题根源在于我们“过度地使用了继承来扩展对象的功能”,由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性;并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀(多继承)。 如何使“对象功能的扩展”能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导... 阅读全文
posted @ 2008-07-04 13:38 Cameo 阅读(334) 评论(0) 推荐(0) 编辑
9. Composite 组合(结构型模式)
摘要:面向对象有一个原则:接口最小化原则.(我们应该把我们对象里尽可能少的接口暴露给外界(一般只暴露业务业务接口)) |内部实现,和内部实现细节的接口不要暴露给客户. 面向对象和设计模式解决的是依懒问题. 动机(Motivation) 上述描述的问题根源在于:客户代码过多地依赖于对象容器复杂的内部实现结构,对象容器内部实现结构(而非抽象接口)的变化将引起客户代... 阅读全文
posted @ 2008-07-01 18:42 Cameo 阅读(346) 评论(0) 推荐(0) 编辑
8. Bridge 桥接(结构型模式)
摘要:抽象与实现 抽象不应该依赖于实现细节,实现细节应该依赖于抽象。 动机(Motivation) 思考上述问题的症结:事实上由于Tank类型的固有逻辑,使得Tank类型具有了两个变化的维度——一个变化的维度为“平台的变化”,一个变化的维度为“型号的变化”。 如何应对这种“多维度的变化”?如何利用面向对象技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化,而不引... 阅读全文
posted @ 2008-06-19 16:05 Cameo 阅读(314) 评论(0) 推荐(0) 编辑
7. Adapter 适配器(结构型模式)
摘要:适配(转换)的概念无处不在…… 适配,即在不改变原有实现的基础上,将原先不兼容的接口转换为兼容的接口。 动机(Motivation) 在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的。 如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口? 意图(... 阅读全文
posted @ 2008-06-11 11:05 Cameo 阅读(276) 评论(0) 推荐(0) 编辑
6. Prototype 原型(创建型模式)
摘要:依赖关系的倒置 抽象不应该依赖于实现细节,实现细节应该依赖于抽象。[原因是抽象变化的频率(速率)慢,细节变化的频率快] – 抽象A直接依赖于实现细节b –抽象A依赖于抽象B,实现细节b依赖于抽象B 动机(Motivation) 在软件系统中,经常面临着“某些结构复杂的对象”的创建工作;由于需求的变化,这些对象经常面临着剧烈的变化,但是它们却拥有比较稳定一致的... 阅读全文
posted @ 2008-06-10 11:28 Cameo 阅读(214) 评论(0) 推荐(0) 编辑
5. Factory Method 工厂方法(创建型模式的基础)
摘要:从耦合关系谈起-耦合关系直接决定着软件面对变化时的行为[设计模式研究的是模块与模块之间的关系] – 模块与模块之间的紧耦合使得软件面对变化时,相关的模块都要随之更改 – 模块与模块之间的松耦合使得软件面对变化时,一些模块更容易被替换或者更改,但其他模块保持不变 一个原则:变化快的东西不要影响变化慢的东西。 接口是模块与模块之间连接的部分,是相对稳定的部分,如下图... 阅读全文
posted @ 2008-06-08 09:28 Cameo 阅读(230) 评论(0) 推荐(0) 编辑
4.Builder 建造者(生成器)(创建型模式)
摘要:最优秀的面向对象就是设计模式,它解决的是一系列变化的问题[设计模式是封装一系列变化].[如果系统没有变化的地方或变化太激烈了,没有不变的地方.这样的情况就不要用设计模式了] Builder模式的缘起 • 假设创建游戏中的一个房屋House设施,该房屋的构建由几个部分组成,且各个部分要富于变化。 • 如果使用最直观的设计方法,每一个房屋部分的变化,都将导致房屋构建的重新修正…… 动机... 阅读全文
posted @ 2008-06-06 09:25 Cameo 阅读(219) 评论(0) 推荐(0) 编辑
3. Abstract Factory 抽象工厂(创建型模式)
摘要:new的问题 常规的对象创建方法: // 创建一个Road 对象 Road road=new Road(); new的问题: – 实现依赖,不能应对“具体实例化类型”的变化。 解决思路: – 封装变化点—— 哪里变化,封装哪里 – 潜台词:如果没有变化,当然不需要额外的封装! 工厂模式的缘起 • 变化点在“对... 阅读全文
posted @ 2008-06-04 14:03 Cameo 阅读(319) 评论(0) 推荐(0) 编辑
2. Singleton单件(创建型模式)
摘要:模式分类 从目的来看: – 创建型(Creational)模式:负责对象创建。 – 结构型(Structural)模式:处理类与对象间的组合。 – 行为型(Behavioral)模式:类与对象交互中的职责分配。 从范围来看: – 类模式处理类与子类的静态关系。 – 对象模式处理对象间的动态关系。 动机... 阅读全文
posted @ 2008-06-02 13:18 Cameo 阅读(285) 评论(0) 推荐(0) 编辑
1. 面向对象设计模式和原则
摘要:设计模式简介: 每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题解决方案的核心. 设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。 面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。 设计模式与面向对象 面向对象设计模式解决的是“类与相互通信的对象之间的组织关系,包括它们的角色、职责、协作方式几个... 阅读全文
posted @ 2008-05-29 16:09 Cameo 阅读(743) 评论(0) 推荐(0) 编辑

点击右上角即可分享
微信分享提示