- 博客(21)
- 资源 (3)
- 收藏
- 关注
原创 设计模式学习笔记二十五(总结)
创建型模式:1、 Singleton模式解决的是实体对象个数的问题。除了Singleton之外,其他创建型模式解决的都是new所带来的耦合关系。2、 Factory Method、Abstract Factory、Builder都需要一个额外的工厂类来负责实例化“易变对象”,而Prototype则是通过原型(一个特殊的工厂类)来克隆“易变对象”。3、 如果遇到“易变类”,起初的设
2008-03-30 00:22:00
501
原创 设计模式学习笔记二十三(Strategy策略模式)
动机:在软件构建过程中,某些对象使用的算法可能多种多样,经常改变,如果将这些算法都编码到对象中,将会使对象变得异常复杂;而且有时候支持不使用的算法也是一个性能负担。如何在运行时根据需要透明地更改对象的算法?将算法与对象本身解耦,从而避免上述问题?意图:定义一系列算法,把它们一个个封装起来,并且使它们可互相替换。该模式使得算法可独立于使用它的客户(客户代码)而变化。基本Code:publ
2008-03-30 00:16:00
623
原创 设计模式学习笔记二十二(State状态模式)
动机:在软件构建过程中,某些对象的状态如果改变,其行为也会随之而发生变化,比如文档处于只读状态,其支持的行为和读写状态支持的行为就可能完全不同。如何在运行时根据对象的状态来透明地更改对象的行为?而不会为对象操作和状态转化之间引入紧耦合?意图:允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。基本Code如下://文档状态枚举public enum Doc
2008-03-30 00:14:00
531
原创 设计模式学习笔记二十一(Memoento备忘录模式)
动机:在软件构建过程中,某些对象的状态在转换过程中,可能由于某种需要,要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态,便会暴露对象的细节实现。如何实现对象状态的良好保存与恢复?但同时又不会因此而破坏对象本身的封装性。意图:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之前保存这个状态,这样以后就可以将该对象恢复到原先保存的状态。基本
2008-03-30 00:10:00
602
原创 设计模式学习笔记二十(Chain of Responsibility职责链模式)
动机:在软件构建过程中,一个请求可能被多个对象处理,但是每个请求在运行时只能有一个接受者,如果显式指定,将必不可少地带来请求发送者与接受者的紧耦合。如何使请求的发送者不需要指定具体的接受者?让请求的接受者自己在运行时决定来处理请求,从而使两者解耦。意图:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递请求,直到有一个对象处理它为止。
2008-03-30 00:04:00
521
原创 设计模式学习笔记十九(Observer观察者模式)
动机:在软件构建过程中,我们需要为某些对象建立一种“通知依赖关系”――一个对象(目标对象)的状态发生改变,所有的依赖对象(观察者对象)都将得到通知。如果这样的依赖关系过于紧密,将使软件不能很好地抵御变化。使用面向对象技术,可以将这种依赖关系弱化,并形成一种稳定的依赖关系。从而实现软件体结构的松耦合。意图:定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到
2008-03-30 00:00:00
571
原创 设计模式学习笔记十八(Iterator迭代器模式)
动机:在软件构建过程中,集合对象内部结构常常变化各异。但对于这些集合对象,我们希望在不暴露其内部结构的同时,可以让外部客户代码透明地访问其中包含的元素(可复用类库ClassLibrary的作者);同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方式 。意图:提供一种方法顺序访问
2008-03-29 23:50:00
516
原创 设计模式学习笔记十七(Mediator中介者模式)
动机:在软件构建过程中,经常会出现多个对象互相关联交互的情况,对象之间常常会维持一种复杂的引用关系,如果遇到一些需求的更改,这咱直接的引用关系将面临不断的变化。在这种情况下,我们可使用一个“中介对象”来管理对象间的关联关系,避免相互交互的对象之间的紧耦合引用关系,从而更好地抵御变化。意图:用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用,从而使其耦合松散,而且可以独立地
2008-03-29 23:44:00
485
原创 设计模式学习笔记十六(Interpreter解释器模式)
动机:在软件构建过中,如果某一特定领域的问题比较复杂,类似的模式不断重复出现,如果使用普通的编程方式来实现将面临非常频繁的变化。在这种情况下,将特定领域的问题表达为某种语法规则下的句子,然后构建一个解释器来解释这样的句子,从而达到解决问题的目的。意图:给定一个语言,定义它的文法的一种表示,并定义一种解释器,这个解释器使用该表示来解释语言中的句子。基本Code: //将汉
2008-03-29 23:39:00
504
原创 设计模式学习笔记十五(Command命令模式)
动机:在软件构建过程中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合――比如需要对行为进行“记录、撤销/重做(undo/redo)、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象,可以实现二者之间的松耦合。意图:将一个请求封装为一个对象,从而使你可用不同的请求对客户(程序,行为请求者)进行参数
2008-03-29 23:36:00
506
原创 设计模式学习笔记十二(Flyweight享元模式)
动机:采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价――主要指内存需求方面的代价。如何避免在大量细粒度的对象问题的同时,让外部客户仍然能够按照面向对象的方式来进行操作就是Flyweight模式要解决的问题。意图:运用共享技术有效地支持大量细粒度对象。基本Code:public class Font //12 bytes+8 bytes=20
2008-03-29 22:54:00
576
原创 设计模式学习笔记十一(Facade外观模式)
动机:组件的客户和组件中的各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化,这种过多的耦合面临着过多的挑战。如何简化外部接口和系统间的交互接口?如何将外部客户程序的演化与内部系统的变化之间的依赖解耦?意图:为子系统中的一组接口提供一个一致的界面,Façade模式定义了一个高层接口,这一接口使得这一子系统更加容易使用。基本Code:internal class Wheel
2008-03-29 22:45:00
522
原创 设计模式学习笔记十(Decorator装饰者模式)
动机:由于继承为类型引入了静态特质,使得这种扩展方式缺乏灵活性;并且随着子类的增多(扩展功能增多),各种子类的组合(扩展功能的组合)会导致更多子类膨胀(多继承)。如何使“对象功能的扩展”能够根据需求来动态地实现?同时避免“扩展功能地增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导致影响将为最低。意图:动态地给一个对象增加一些额外的职责。就增加功能而言,Decorator模式比生成
2008-03-29 22:41:00
492
原创 设计模式学习笔记九(Composite组合模式)
动机:客户代码过多地依赖于对象容器复杂的内部实现结构,对象容器内部实现结构(而非对象接口)的变化将引起客户端代码的频繁变化,带来代码的维护性、扩展性等弊端。如何实现“客户代码与复杂的对象容器结构”进行解耦?让对象容器自己来实现自身的复杂结构,从而使得客户代码就像使用简单对象一样来处理复杂的对象容器。意图:将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得用户对单个对
2008-03-29 22:36:00
523
原创 设计模式学习笔记八(Bridge桥接模式)
动机:对象具有两个以上的维度变化。如何利用面向对象技术来解决该问题,而不引入额外的复杂度。意图:将抽象部分与实现部分分离(一个事物中多个维度变化相分离),使得它们都可以独立地变化。 基本Code:public abstract class Tank{ public abstract void Shot(); public abstract void Ru
2008-03-29 22:18:00
508
原创 设计模式学习笔记七(Adapter适配器模式)
适配,即在不改变原有实现的基础上,将原先不兼容的接口转换为兼容的接口。动机:在软件系统中,由于应用环境的变化,常常需要将“一些现存对象”放在新的环境中使用,但是新环境中要求的接口是这些现存对象不能满足的。如何应对这种“迁移的变化”,如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口。意图:将一个类的接口转换成客户需要的另一个接口。Adapter模式使得原本由于接口不兼容而
2008-03-29 21:50:00
442
原创 设计模式学习笔记六(Prototype原型模式)
抽象不应该依赖于实现细节,实现细节应该依赖于抽象。动机:在软件系统中,经常面临着“某些结构复杂的对象”的创建工作;由于需求的变化,这些对象经常面临着剧烈的变化,但它们却拥有比较稳定一致的接口。如何向“客户程序(使用这些对象的程序)”隔离出“这些易变的对象”,从而使得“使用这些易变对象的客户程序”不随着需求的改变而改变。意图:使用原型实例指定创建对象的种类,然后通过拷贝这些原型来创建新的对象
2008-03-29 21:34:00
551
原创 设计模式学习笔记五(Factory Method 工厂方法模式)
设计原则:松耦合,高内聚动机:在软件系统中,经常面临着“某个对象”的创建工作,由于需求的变化,这个对象的具体实现经常面临着剧烈的变化,但是它却拥有比较稳定的接口。所有,我们需要提供一种“封装机制”来隔离出这个“易变对象”的变化,从而保持系统中“其它依赖该对象的对象”不随着需求的改变而改变。意图:定义一个对象的接口,让子类决定实例化那一个类。Factory Method使得一个类的实例化延迟
2008-03-29 21:01:00
656
原创 设计模式学习笔记四(Builder生成器模式)
动机:在软件系统中,有时候面临着“一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临剧烈的变化,但是将它们组合在一起的算法却相对稳定。如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化,从而保持系统中的“稳定构建算法”不随着需求的改变而改变。意图:就是将一个复杂对象的构建与其表示相分离,使得同样的构建过程可以创建不同
2008-03-29 20:48:00
457
原创 设计模式学习笔记二(Singleton单件模式)
意图:保证一个类仅有一个实例,并提供一个该实例的全局访问点。基本Code:public class Singleton{ private static Singleton instance; Private Singleton() { } public static Singleton Instance {
2008-03-29 20:26:00
445
原创 设计模式学习笔记一(概述)
设计模式描述了软件设计过程中某一类常见性问题的一般性解决方案。面向对象设计模式描述了面向对象设计过程中,特定场景下、类与相互通信的对象之间常见的组织关系。好的面向对象设计是指那些可以满足“应对变化,提高复用”的设计。面向对象设计模式不像算法技巧,可以照搬照抄,它是建立在“面向对象”纯熟、深入理解的基础上的经验性认识,掌握面向对象设计模式的前提是首先掌握“面向对象”。
2008-03-26 21:28:00
598
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人