![](https://img-blog.csdnimg.cn/20201014180756918.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
设计模式
yangjxyang
这个作者很懒,什么都没留下…
展开
-
设计模式之Mediator
单纯两个对象之间的通信或者是交互是非常简单的,只要互相拥有对方的引用。 但是,对象多了的话就会难以维护,不同对象间的通信方式不一致。 并且保留有引用,增加了耦合度。 这时候就需要一个管理者。 Mediator出现了。 表面看起来,原本的Colleague-Colleague的关系变成了比较复杂的Colleage-Mediator-Colleage的关系。 然而,从整体来看,原本的多对多...2012-03-09 03:42:54 · 89 阅读 · 0 评论 -
设计模式之Factory(Simple Factory,Factory Method,Abstract Factory)
工厂,要生产的是各种各样的产品。 Simple Factory,简单工厂,就是最基本的根据传进来的参数来决定生产的是何种产品。 所以,明显的硬编码,采用if,else来实现。 改进方法:Factory Method,工厂方法。 工厂方法将创建产品推迟到了工厂类的子类去。不同的子类分别生产不同的产品。 但是,问题又来了,一种工厂子类生产一种产品。但如果,某种产品又有不同的型号呢...原创 2012-03-13 00:48:12 · 89 阅读 · 0 评论 -
设计模式之Flyweight
Flyweight模式中文为“享元”模式。 当有某个部分被不断地重复使用的情况下,每次创建一次对象,该共同部分总是被重复创建。 这种情况下,效率是比较低的。 所以,应该将该共同部分提取出来。成为“共享单元”。 Flyweight模式促进细粒度对象的重复使用,提高存在大量对象环境下的使用效率。 参考: 模式Flyweight Flyweight...2012-03-12 18:51:28 · 64 阅读 · 0 评论 -
设计模式之Adapter与Facade
Adapter是为了使不同的接口能够一起工作,将一个已有的接口转换成另一个已有的接口。 Adapter是为了重用与期望接口不一致但的确可以被重用的代码。 Facade模式,是为了减小模块间的耦合而在更高层次上定义的接口,Facade模式简化了接口。 ...2012-03-12 01:50:26 · 103 阅读 · 0 评论 -
设计模式之Decorator
Decorator主要目的是为类增加新的功能。 那么,为什么不用继承呢? 原因是一,如果要增加的功能比较多,则继承会生成很多的子类。 二,使用继承,则新的功能是在编译器就决定了的。而更多的时刻我们更愿意在运行期时指定新的功能。即由用户动态指定。 Decorator看起来和Composite很像。但是,很明显,Composite模式更强调的是层次关系,即P...2012-03-12 01:27:42 · 77 阅读 · 0 评论 -
设计模式之Bridge
将抽象与实现部分分离,使得各自能够独立变化。 一个抽象类的派生类需要使用多种实现,这个时候如果采用继承的方式,则派生类数量会呈现爆炸式增长,并且派生类依赖于具体实现。 这个时候,采用组合代替继承。 抽象是变化的,实现也是变化的。这个时候就应该使用Bridge模式。 Service层与Dao层采用的就是Bridge模式。 参考资料:http:...原创 2012-03-12 00:53:57 · 66 阅读 · 0 评论 -
设计模式之Visitor
State模式将不同的状态与与其对应的行为封装在了State对象中。 而Visitor模式却是将结构与行为分离开。 不同的结构产生不同的行为。 但是,大量的if和else让我们感到厌烦。 于是乎,Visitor出现了。 模式的控制权在Element/Visitable手上。其accept(Visitor)方法规定了其是否可以被Visitor访问。 Visitor可以访问El...2012-03-11 02:40:46 · 76 阅读 · 0 评论 -
设计模式之State
设计模式最重要的一个原则是封装变化。 一个对象如果有不同的状态,在不同状态下有不同的行为。 正常情况下,我们会用if和else语句来处理。可是,如果状态很多了,那么就会有非常多的if和else了。系统扩展性差。 State模式最重要的就是将变化的状态和行为封装起来。 原本Context中有一个表示状态的常量。 现在,在Context对象中维护一个State对象。在所有与State有关的r...2012-03-11 00:31:10 · 65 阅读 · 0 评论 -
设计模式之Command
一个Invoker与一个Receiver之间的命令传递原本很简单,但是一个Invoker对应多个Receiver呢? 这个时候单一的Invoker-Receiver模式已经不能满足需求了。 所以,我们将模式变成了Invoker-Command-Receiver模式,Invoker与Receiver因此解耦。我们不需要继续在Invoker内部维护大量的Receiver,而是采用在Invoker内...2012-03-10 04:04:39 · 69 阅读 · 0 评论 -
设计模式之Memento
当需要恢复restore时,通常将Originator的状态备份到Memento中,从而不破坏封装。 Memento的维护控制靠的是Caretaker。 所以,Memento模式带有典型的MVC模式。 Caretaker是控制器, Memento是模型, Originator是视图。 故,Caretaker内部有Memento的引用,而Originator依赖于Memento。Care...2012-03-10 03:22:51 · 76 阅读 · 0 评论 -
设计模式之Builder
我们自己玩堆积木也许没问题。 但是,如果要我们亲自去盖个大楼就有很多问题了。 这个时候,我们宁愿当个设计师。而具体的其他实际盖房步骤交给建筑工人去完成。 这就是Director与Builder。Director指导Builder。 最终,我们是去先Builder要东西的,故Builder有个getResult()方法。 用Builder模式有个好处,那就是Builder具体的实现细...2012-03-13 01:33:06 · 73 阅读 · 0 评论