dongliheng的专栏

 装饰模式:Decorator常被翻译成"装饰",我觉得翻译成"油漆工"更形象点,油漆工(decorator)是用来刷油漆的,那么被刷油漆的对象我们称decoratee.这两种实体在Decorator模式中是必须的. Decorator定义:动态给一个对象添加一些额外的职责,就象在墙上刷油漆.使用Decorator模式相比用生成子类方式达到功能的扩充显得更为灵活.为什么使用Deco

 Template模板模式定义:定义一个操作中算法的骨架,将一些步骤的执行延迟到其子类中.使用Java的抽象类时，就经常会使用到Template模式,因此Template模式使用很普遍.而且很容易理解和使用。  public abstract class Benchmark{　　/**　　* 下面操作是我们希望在子类中完成　

Composite模式定义:将对象以树形结构组织起来,以达成“部分－整体” 的层次结构，使得客户端对单个对象和组合对象的使用具有一致性.Composite比较容易理解，想到Composite就应该想到树形结构图。组合体内这些对象都有共同接口,当组合体一个对象的方法被调用执行时，Composite将遍历(Iterator)整个树形结构,寻找同样包含这个方法的对象并实现调用执行。可以用牵一动百来形

Facade模式的定义: 为子系统中的一组接口提供一个一致的界面.Facade一个典型应用就是数据库JDBC的应用,如下例对数据库的操作: public class DBCompare { 　　Connection conn = null;　　PreparedStatement

工厂模式定义:提供创建对象的接口.为何使用?工厂模式是我们最常用的模式了,著名的Jive论坛 ,就大量使用了工厂模式，工厂模式在Java程序系统可以说是随处可见。为什么工厂模式是如此常用？因为工厂模式就相当于创建实例对象的new，我们经常要根据类Class生成实例对象，如A a=new A() 工厂模式也是用来创建实例对象的，所以以后new时就要多个心眼，是否可以考虑实用工厂模式，虽然这样

原型模式定义:用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象.Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节,工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。如何使用?因为Java中的提供clone()方法来实现对象的克隆,所以Prototype模式实现一下子变

Builder模式定义:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.Builder模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们.用户不知道内部的具体构建细节.Builder模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到.为何使用?是为了将构建复杂对象的过程和它的部件解耦.注意: 是解耦过程和

关于代码重复最著名的单词是Kent Beck的Once And Only Once，也就是说软件操作的任何一个片断--不管是一个算法，一个常量集合，用于阅读的文档或者其他东西--应当只出现一次。 软件重复出现至少会导致以下问题： · 其中的一个版本会过期 · 代码的责任会四处散开，导致代码难以理解 · 当你修改代码时，需要重复修改很多地方，一不小心就会遗漏 · 你不能很好地进行性能优化 我以前

多变且复杂的需求　　如果没有多变的需求，也许就没有今天的面向对象软件，我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击，可是这样下去的结果只有一个：使得软件更加僵化；或者程序员更加 劳累。　　需求不但多变，而且经常是不可能第一次就能掌握，需求反映了某个领域的专业知识，例如数学、管理、财务或 电子商务等等，每个特定案例需求又有其特别复杂之处，几乎没有人能够第

Interpreter解释器模式定义:定义语言的文法 ,并且建立一个解释器来解释该语言中的句子.Interpreter似乎使用面不是很广,它描述了一个语言解释器是如何构成的,在实际应用中,我们可能很少去构造一个语言的文法.我们还是来简单的了解一下:首先要建立一个接口,用来描述共同的操作.public interface AbstractExpression { 　　 void inte

非模式思维的惩罚面向对象软件体系是和面向过程体系格格不入的，面向对象的各种技术如单元测试　性能缓存等等都是OO体系，如果我们没有具备模式思维来编程，由此而诞生的软件架构必然失败，失败在哪里？通过性能惩罚你。最近碰到一个台湾的钢铁架构，它虽然包含一个简单的MVC框架，但是其Controller实际又是Service，该框架配置将下面几个元素耦合在一起：页面流程；控制类；Dao与VO，这实际是将表现层

Command模式是最让我疑惑的一个模式,我在阅读了很多代码后,才感觉隐约掌握其大概原理,我认为理解设计模式最主要是掌握起原理构造,这样才对自己实际编程有指导作用.Command模式实际上不是个很具体,规定很多的模式,正是这个灵活性,让人有些confuse.Command定义n 将来自客户端的请求传入一个对象，无需了解这个请求激活的 动作或有关接受这个请求的处理细节。这是一种两台机器之间通

State模式的定义: 不同的状态,不同的行为;或者说,每个状态有着相应的行为.何时使用?State模式在实际使用中比较多,适合"状态的切换".因为我们经常会使用If elseif else 进行状态切换, 如果针对状态的这样判断切换反复出现,我们就要联想到是否可以采取State模式了.不只是根据状态,也有根据属性.如果某个对象的属性不同,对象的行为就不一样,这点在数据库系统中出现频率比较

Mediator中介者模式定义:用一个中介对象来封装一系列关于对象交互行为.为何使用Mediator?各个对象之间的交互操作非常多;每个对象的行为操作都依赖彼此对方,修改一个对象的行为,同时会涉及到修改很多其他对象的行为,如果使用Mediator模式,可以使各个对象间的耦合松散,只需关心和 Mediator的关系,使多对多的关系变成了一对多的关系,可以降低系统的复杂性,提高可修改扩展性.如

Visitor访问者模式定义作用于某个对象群中各个对象的操作. 它可以使你在不改变这些对象本身的情况下,定义作用于这些对象的新操作.在Java中,Visitor模式实际上是分离了collection结构中的元素和对这些元素进行操作的行为.为何使用Visitor?Java的Collection(包括Vector和Hashtable)是我们最经常使用的技术,可是Collection好象是个黑色

Flyweight模式定义:避免大量拥有相同内容的小类的开销(如耗费内存),使大家共享一个类(元类).为什么使用?面向对象语言的原则就是一切都是对象,但是如果真正使用起来,有时对象数可能显得很庞大,比如,字处理软件,如果以每个文字都作为一个对象,几千个字,对象数就是几千,无疑耗费内存,那么我们还是要"求同存异",找出这些对象群的共同点,设计一个元类,封装可以被共享的类,另外,还有一些特性是取决

Chain of Responsibility定义Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求request,这些类之间是一个松散的耦合,唯一共同点是在他们之间传递request. 也就是说，来了一个请求，A类先处理，如果没有处理，就传递到B类处理，如果没有处理，就传递到C类处理，就这样象一个链条(chain)一样传递下去。如何使用?

Strategy策略模式是属于设计模式中 对象行为型模式,主要是定义一系列的算法,把这些算法一个个封装成单独的类.Stratrgy应用比较广泛,比如, 公司经营业务变化图, 可能有两种实现方式,一个是线条曲线,一个是框图(bar),这是两种算法,可以使用Strategy实现.这里以字符串替代为例, 有一个文件,我们需要读取后,希望替代其中相应的变量,然后输出.关于替代其中变量的方法可能有多

 理解并使用设计模式,能够培养我们良好的面向对象编程习惯,同时在实际应用中,可以如鱼得水,享受游刃有余的乐趣.代理模式是比较有用途的一种模式,而且变种较多,应用场合覆盖从小结构到整个系统的大结构,Proxy是代理的意思,我们也许有代理服务器等概念,代理概念可以解释为:在出发点到目的地之间有一道中间层,意为代理.设计模式中定义: 为其他对象提供一种代理以控制对这个对象的访问.为什么要

适配器模式定义:将两个不兼容的类纠合在一起使用，属于结构型模式,需要有Adaptee(被适配者)和Adaptor(适配器)两个身份.为何使用?我们经常碰到要将两个没有关系的类组合在一起使用,第一解决方案是：修改各自类的接口，但是如果我们没有源代码，或者，我们不愿意为了一个应用而修改各自的接口。 怎么办? 使用Adapter，在这两种接口之间创建一个混合接口(混血儿).如何使用?实现Ad

Memento备望录模式定义:memento是一个保存另外一个对象内部状态拷贝的对象.这样以后就可以将该对象恢复到原先保存的状态.Memento模式相对也比较好理解,我们看下列代码: public class Originator { 　　 private int number; 　　private Fil

现在Java领域各种技术百花齐放，名目繁多，如何根据自己的需求选择这些框架呢？特别对于初学者，在学习选择方向上也非常迷茫，如何有针对性的根据自己项目特点进行学习就变的更加重要。　　下面我们从一个发展角度来对J2EE/Java EE的这些框架诞生进行一番考量，可能对我们的选择有很大帮助。　　首先我们需要明白一个高质量的J2EE系统是什么样子？高质量的J2EE/Java EE系统标准实际就是O

越来越多人开始使用Java，但是他们大多数人没有做好足够的思想准备(没有接受OO思想体系相关培训)，以致不能很好驾驭Java项目，甚至 导致开发后的Java系统性能缓慢甚至经常当机。很多人觉得这是Java复杂导致，其实根本原因在于：我们原先掌握的关于软件知识(OO方面)不是太贫乏就是不恰当，存在认识上和方法上的误区。软件的生命性　　软件是有生命的，这可能是老调重弹了，但是因为它事关分层架构