`
文章列表

设计模式之Bridge

 
将抽象与实现部分分离,使得各自能够独立变化。   一个抽象类的派生类需要使用多种实现,这个时候如果采用继承的方式,则派生类数量会呈现爆炸式增长,并且派生类依赖于具体实现。 这个时候,采用组合代替继承。   抽象是变化的,实现也是变化的。这个时候就应该使用Bridge模式。   Service层与Dao层采用的就是Bridge模式。           参考资料:http://www.iteye.com/topic/57178                 Bridge - 桥接模式
State模式将不同的状态与与其对应的行为封装在了State对象中。   而Visitor模式却是将结构与行为分离开。 不同的结构产生不同的行为。 但是,大量的if和else让我们感到厌烦。 于是乎,Visitor出现了。   模式的控制权在Element/Visitable手上。其accept(Visitor)方法规定了其是否可以被Visitor访问。 Visitor可以访问Element的内部状态但是不可以改变其结构。 Visitor必须为每一个 具体的Element 定义一个可以被访问的的接口。   所以,使用Visitor模式最好是保持Visitor稳定不变。即 ...
设计模式最重要的一个原则是封装变化。 一个对象如果有不同的状态,在不同状态下有不同的行为。 正常情况下,我们会用if和else语句来处理。可是,如果状态很多了,那么就会有非常多的if和else了。系统扩展性差。 State模式最重要的就是将变化的状态和行为封装起来。 原本Context中有一个表示状态的常量。 现在,在Context对象中维护一个State对象。在所有与State有关的request方法中调用State的handle方法即可,即委托给自己维护的State对象来处理。   使用State模式,要注意拥有不同状态的对象可以接受的请求(消息)是一致的。 至于如何切换状态 ...
一个Invoker与一个Receiver之间的命令传递原本很简单,但是一个Invoker对应多个Receiver呢? 这个时候单一的Invoker-Receiver模式已经不能满足需求了。 所以,我们将模式变成了Invoker-Command-Receiver模式,Invoker与Receiver因此解耦。我们不需要继续在Invoker内部维护大量的Receiver,而是采用在Invoker内部指定Command,再通过Command指定Receiver来处理相关的命令。 该模式将请求封装成一个对象。
当需要恢复restore时,通常将Originator的状态备份到Memento中,从而不破坏封装。 Memento的维护控制靠的是Caretaker。 所以,Memento模式带有典型的MVC模式。 Caretaker是控制器, Memento是模型, Originator是视图。 故,Caretaker内部有Memento的引用,而Originator依赖于Memento。Caretaker负责保存Memento,Originator仅仅是使用Memento而已。这就是三者的简单关系。 Memento的典型运用有表单提交时,如果某个字段验证失败了,那么返回原来页面时,仍然能够保 ...
单纯两个对象之间的通信或者是交互是非常简单的,只要互相拥有对方的引用。 但是,对象多了的话就会难以维护,不同对象间的通信方式不一致。 并且保留有引用,增加了耦合度。 这时候就需要一个管理者。 Mediator出现了。 表面看起来,原本的Colleague-Colleague的关系变成了比较复杂的Colleage-Mediator-Colleage的关系。 然而,从整体来看,原本的多对多的关系变成了一对多的关系。   Mediator是一个“极度偷懒”的调度者。自己没有真正地做任何东西。 底层的东西还是由Colleage去做的。
Java内存分配: 1. 寄存器:我们在程序中无法控制 2. 栈:存放基本类型的数据和对象的引用,但对象本身不存放在栈中,而是存放在堆中 3. 堆:存放用new产生的数据 4. 静态域:存放在对象中用static定义的静态成员 5. 常量池 ...
Global site tag (gtag.js) - Google Analytics