posts - 262,  comments - 221,  trackbacks - 0
模式与重构
设计模式总结-Visitor模式      摘要: Visitor模式的一个优点体现在对集合元素的访问中:由于集合中的可访问元素都实现了Visitable接口,所以在迭代集合的过程中,我们可以将每个元素都看成是接口类型。

其次由于JAVA语言的多态性,虽然每个元素都是接口类型(Visitable),但每个元素的实现类不同,所以在调用accept方法时,虚拟机“知道”应该调起那个正确的方法(例如:集合中的一个String元素,会调用StringElement的accept方法)  阅读全文
posted @ 2008-04-15 17:38 Paul Lin 阅读(4455) | 评论 (2)  编辑
设计模式总结-Strategy模式      摘要: 策略操作定义了策略的输入和输出,而把策略的实现工作留给了各个类。这些类以不同的方案来实现同一操作,它们为用户提供统一的接口,因而这些类可以相互替换。

Strategy模式允许多种策略共存,而代码不会混乱。策略模式也可以实现模式选择逻辑和策略本身相分离。

Strategy模式的意图在于把可选的策略或方案封装在不同的类中,并在这些类中实现一个共同的操作。  阅读全文
posted @ 2008-04-08 11:52 Paul Lin 阅读(5334) | 评论 (2)  编辑
设计模式总结-State模式      摘要: 使用状态模式后,客户端外界可以直接使用事件Event实现,根本不必关心该事件导致如何状态变化,这些是由状态机等内部实现。这是一种Event-condition-State,状态模式封装了condition-State部分。

每个状态形成一个子类,每个状态只关心它的下一个可能状态,从而无形中形成了状态转换的规则。如果新的状态加入,只涉及它的前一个状态修改和定义。  阅读全文
posted @ 2008-04-07 18:02 Paul Lin 阅读(7587) | 评论 (2)  编辑
设计模式总结-Command模式      摘要: 让方法运行最常见的方式是调用之,但是在很多情况下,我们不能控制和提供方法执行的上下文和时机。这种情况下,可以把方法封装在对象中。通过在对象中存储调用方法所需的信息,就可以让客户端或者服务决定何时调用这个方法。

Command模式的意图是把请求封装在对象中。

--摘自《Java设计模式》第24章:Command(命令)模式
  阅读全文
posted @ 2008-04-07 15:13 Paul Lin 阅读(3447) | 评论 (0)  编辑
设计模式总结-Memento模式(二)      摘要: Memento模式和其它模式的结合应用:

一、“Mementor”模式和“堆栈”的结合-“GUI界面撤销功能”的实现
二、“Mementor”模式和“Observer”模式的结合-“通知式恢复”
三、“Mementor”模式和“Observer”模式、“责任链”模式的结合-“链式通知恢复”
四、“Mementor”模式和“Flyweight”模式的结合:减少相同对象的拷贝  阅读全文
posted @ 2008-03-22 17:59 Paul Lin 阅读(1714) | 评论 (1)  编辑
设计模式总结-Memento模式(一)      摘要: Memento模式的特点:

在需要提供保存、恢复对象状态的类中,必须提供两个方法:

.保存对象当前状态方法:将对象自身(this)作为参数传入,创建备忘录。
.恢复对象之前状态的方法:取出备忘录/接收一个备忘录对象,从中获取对象之前的状态

模式的缺点是耗费大,如果内部状态很多,再保存一份,无意要浪费大量内存.

注意:Memento模式保存的是操作前对象的状态,而不是操作后对象的状态;否则就没办法做恢复了  阅读全文
posted @ 2008-03-22 17:56 Paul Lin 阅读(2186) | 评论 (0)  编辑
设计模式总结-Observer模式      摘要: 下面是Observer模式的实现过程:

·创建一个被观察者,继承java.util.Observable

·创建一个观察者,实现java.util.Observer接口

·注册观察着,调用addObserver(Observer observer)

·在被观察者改变对象内部状态的地方,调用setChanged()方法,然后调用notifyObservers(Object)方法,通知被观察者

·在观察者的update(Object)方法中,对改变做出响应。  阅读全文
posted @ 2008-03-07 13:55 Paul Lin 阅读(3056) | 评论 (0)  编辑
设计模式总结-Flyweight模式      摘要: Flyweight模式一般由几个部分组成:

·Flyweight接口(抽象类) :定义了一个可共享的元类
·Flyweight实现类:实现了元类中的操作,而且可能会提供一个用于保存内部状态(共享属性)的空间
·Flyweight Factory:创建Flyweight的工厂类,创建后将其保存到Flyweight Pool中
·Flyweight Pool:缓冲Flyweight对象的池,通常包含在工厂类中  阅读全文
posted @ 2008-03-05 14:33 Paul Lin 阅读(2949) | 评论 (0)  编辑
设计模式总结-Bridge模式      摘要: ·在抽象接口中包含了一个对行为接口的引用,这样的话行为的操作将完全委托给行为接口完成,抽象类无需关心。

·在抽象类的继承子类中,调用了行为类的子类来实现不同的行为。此时抽象类的子类中只知道属性,但不知道具体的行为实现,实现了概念与行为的分离

·在行为类的继承子类中,只知道执行相应的动作,但不知道具体的属性,实现了行为和概念的分离  阅读全文
posted @ 2008-02-26 21:48 Paul Lin 阅读(2062) | 评论 (0)  编辑
设计模式总结-Decorator模式(二)      摘要: Decorator模式的实际应用--动态黑名单过滤  阅读全文
posted @ 2008-02-19 18:31 Paul Lin 阅读(1750) | 评论 (0)  编辑
设计模式总结-Decorator模式      摘要: Decrator模式的适用场合:
1).在运行时刻由用户动态决定加入的方式和时机,无法在编译期间决定
2).需要改变的行为太多,用继承会导致复杂性的增加  阅读全文
posted @ 2008-02-19 16:33 Paul Lin 阅读(2068) | 评论 (0)  编辑
设计模式总结-Composite模式(一)      摘要: Composite模式的特点:
·Composite模式一般都有一个抽象类或接口来表示最基本的构件。
·Composite模式一般都由两类对象构成:表示单个元素的对象(Primitive)和表示多个元素组合的对象(Composite)
·Composite模式下Primitive和Composite对象都继承或实现上层接口或父类
·Composite模式下每个构件都含有三个基础方法:add(构件)、remove(构件)、iterator()
·Composite对象含有一个用来保存其下所有基础元素的的集合,例如:Vector,ArrayList,HashMap
·Composite对象的方法被调用时一般都会引起其下所有基础元素相同方法的调用,即递归调用。  阅读全文
posted @ 2008-01-21 09:55 Paul Lin 阅读(3104) | 评论 (0)  编辑
设计模式总结-Adapter模式      摘要: 从上面的四种方式来看,方式二最简单也最常用,方式三最灵活,方式一和四有相同的地方就是都继承了其中的某一个类,这样就限制了适配器的子类不能再继承其它的功能父类了,不同的地方是方式一使用委托的方式来完成类B的功能,而方式四则自己实现了接口的方法。  阅读全文
posted @ 2008-01-14 17:50 Paul Lin 阅读(1421) | 评论 (0)  编辑
设计模式总结-Proxy模式      摘要: Proxy类具有几个特点

·Proxy类一般都实现或继承了后台对象接口或抽象类,在其中实现了后台对象接口的方法,这样外界和代理类打交道的客户端看到的是和后台对象一样的接口。根本不知道自己在和代理对象打交道。

·Proxy类一般都含有一个后台对象作为其成员,因为代理类需要在其实现接口的方法中调用后台对象的真正方法来实现业务逻辑。

·Proxy类一般都需要包含一个能够验证用户请求是否合法的对象,如上例中的ForumPermisssions类,作为转发或拒绝用户请求的判断依据  阅读全文
posted @ 2008-01-14 17:40 Paul Lin 阅读(1476) | 评论 (0)  编辑
设计模式总结-单例模式      摘要: 在多线程环境下,我们无法保证一个方法能够持续运行到结束,其他线程的方法才开始运行。因而可能存在这样一种情形:两个线程几乎同时尝试初始化单例类。假设第一个方法发现单例为空,而第二个方法在此刻开始运行,它也会发现该单例为空。接下来,这两个方法都将对该单例进行初始化  阅读全文
posted @ 2008-01-03 22:31 Paul Lin 阅读(1185) | 评论 (0)  编辑
设计模式总结-Builder模式(二)      摘要: 使用Builder模式的最佳场合应该是:对象的构建过程长或复杂、构建对象所需的全部参数无法在一开始就完全获得,必须通过一步步的交互过程来获取。例如:通过Web页面的输入或用户选择来构建所需对象  阅读全文
posted @ 2008-01-02 23:51 Paul Lin 阅读(1596) | 评论 (2)  编辑
设计模式总结-Builder模式      摘要: 所以我们可以将Builder模式分成四个组成部分:·产品:public interface Product·零件:Public interface Part·生产零件的过程:public interfact Builder·组装零件的过程:public class Director   阅读全文
posted @ 2008-01-02 23:01 Paul Lin 阅读(486) | 评论 (0)  编辑
设计模式总结-Prototype模式      摘要: Prototype模式最适用的场合应该是:当几个对象的类仅在属性上存在一点差异,而行为上完全相同时。可以在复制一个原型对象后,对其属性进行细小的微调,从而实现定制化的目的。  阅读全文
posted @ 2008-01-02 22:59 Paul Lin 阅读(2003) | 评论 (0)  编辑
设计模式总结-工厂模式      摘要: 从上面的4种方式来看,方式1~3适合于工厂所产生的对象都是属于同一个父类型的,而方式4则适合于工厂需要产生多种类型的产品,而每一种类型的产品下面又有多个子类型的情况。
  阅读全文
posted @ 2008-01-02 22:54 Paul Lin 阅读(431) | 评论 (0)  编辑

<2024年3月>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

常用链接

留言簿(21)

随笔分类

随笔档案

BlogJava热点博客

好友博客

搜索

  •  

最新评论

阅读排行榜

评论排行榜