此鸟不鸣

模式,模式的种类

zhouzhao21 — Fri, 06 Jun 2008 06:46:21 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/200736 发表时间: 2008年06月06日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

有些人常常使用设计模式（Design Pattern）一词来指所有直接处理软件的架构、设计、程序实现的任何种类的模式。另外一些人则强调要划分三种不同层次的模式：架构模式（Architectural Pattern）、设计模式（Design Pattern）、成例（Idiom）。成例有时称为代码模式（Coding Pattern）。

Architectural Pattern ：
一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。
一个架构模式常常可以分解成很多个设计模式的联合使用。
Design Pattern ：
一个设计模式提供一种提炼子系统或软件系统中的组件或者它们之间的关系的纲要设计。
设计模式描述普遍存在的在相互通信的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
Coding Pattern(Idiom) ：
代码模式（或成例）是较低层次的模式，并与编程语言密切相关。代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。

这三者之间的区别在于三种不同的模式存在于它们各自的抽象层次和具体层次上。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

PureMVC 中文最佳实践

zhouzhao21 — Thu, 05 Jun 2008 10:21:42 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/200395 发表时间: 2008年06月05日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

介绍：
PureMVC是一个定位于设计高性能RIA客户端的基于模式的框架。现在它已经被移植到其他的平台上，包括服务器端环境。
PureMVC由controller、Model 、view 三个子系统构成的，由Facade，实现统一管理的一个系统架构。

以前使用过一段时间 PureMVC ，看的全都是英文资料，今偶然发现中文版的最佳实践已经出来了，特发出来与大家共享。
地址：
http://puremvc.org/component/option,com_wrapper/Itemid,183/
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

在 eclipse 中使用 tomcat 像开发普通 JEE 项目一样开发 RED5 项目

zhouzhao21 — Fri, 23 May 2008 11:41:20 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/195969 发表时间: 2008年05月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

介绍：
Red5是一个采用Java开发开源的Flash流媒体服务器。它支持：把音频（MP3）和视频（FLV）转换成播放流；录制客户端播放流（只支持FLV）；共享对象；现场直播流发布；远程调用。Red5使用RSTP作为流媒体传输协议，在其自带的一些示例中演示了在线录制，flash流媒体播放，在线聊天，视频会议等一些基本功能。

版本：
RED5 0.7
eclipse3.3.1
myeclipse 5.1
tomcat 6.0.16

下载 Red5War_0.7.0.zip 。

1。查看 %TOMCAT_HOME/conf/Catalina/localhost 目录下是否有与 RED5 项目名称相同的文件夹，有则删除。
2。清空 %TOMCAT_HOME/work/Catalina/localhost 目录下是否有与 RED5 项目名称相同的文件夹，有则删除。
3。将 red5 war 文件一个 war 文件（如 root.war ）放在 %TOMCAT_HOME/webapps 目录下（注意此目录下不要含有与 red5 war 文件名称相当的目录）。
4。解压 red5 war 文件（可以通过启动 Tomcat 解压）。
5。查看 WEB-INF/web.xml 文件，将其需要的 WEB-INF/classes 目录中的文件 cut 出来（如 *-web.xml ）。
6。将 red5 war 解压后目录中 WEB-INF/classes 目录文件打包为 jar 文件放在 WEB-INF/lib 目录中。

7。在 eclipse 中新建 web 项目。将步骤 5 中 cut 出来的文件 paste 到新项目的 src 目录下。将 tomcat 目录下的 red5 war 解压后目录 copy 到新建项目的 WebRoot 目录下。
8。更改 web.xml 与 src 下面的配置文件，将原来的 red5 项目名称更改为当前项目名称（因不同 red5 war 文件对应的要更改的文件不同，在此就不一一指出）。

9。在 myeclipse 中启动 Tomcat（在启动时会抛出 class not find 异常，异常出现在 src 目录下的 admin-web.xml ，由于我用不到这个文件，直接把他删除了）。

至此我们已经把 red5 项目完美的整合在自己的项目中，可以在 eclipse 中象开发普通 JEE 应用程序一样开发 red5 项目了。

补充：如果你不想要 red5 自代的 demo 可以把不想要的配置文件删除（*-web 文件），Red5使用的日志文件为第六步中生成的 jar 文件中的 logback.xml，并不是使用程序中的 log4j.properties 。不过可以将其提取出来放在自己的类路径下。附件为抽取后的 red5

郁闷，被转载了......
转载请标明出处：
http://kyocc.javaeye.com/blog/195969
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

java NIO Socket 总结

zhouzhao21 — Tue, 20 May 2008 20:59:48 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/195020 发表时间: 2008年05月20日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

对于服务器 socketChannel （ServerSocketChannel），唯一（也只能）关心的操作是 OP_ACCEPT（表示一个新的客户端连接）。
一般一个线程应可以共享一个 Buffer 。
在没有客户端请求时，Selector.select() 将一直堵塞。应该将此做为唯一的堵塞时刻（在 I/0 Socket 中，在读数据时也会堵塞），做为服务器一般会无限循环此条件。
在自 Selector.selectedKeys().iterator() 中得到的 SelectionKey 时，就应该调用 iterator 的remove() 方法将其自集合中删除，防止忘记删除或删除地点不统一。
客户端的读或写等操作应在 ServerSocketChannel 的 OP_ACCEPT 事件中进行初始注册（注册后会在下一次 Selector.select() 循环时调用）。即注册与客户端建立连接后要做的事情。然后在其他相应的操作中注册其他事件（一次会话在不同事件中相互调用）。
在 OP_ACCEPT 事件中应将客户端通道设置为非阻塞模式以允许服务器处理多个并发连接。
在读或写操作时应将对 Buffer 的操作放在循环中，以免一次不能处理完毕 Buffer 中的全部数据。
一次循环有时只能处理读或写的一部分操作（视 Buffer 大小与传递数据多少等而定），剩余数据将在下一次 Selector.select() 循环时处理，这与 I/O Socket 中等待数据全部到达时再处理从根本上不相同，要转变思想。
若希望关闭与客户端的会话只需将客户端通道关闭即可。
深入研究了 NIO Socket ，才深深体会到 Apache MINA 设计的美妙！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

2008 中国

zhouzhao21 — Tue, 13 May 2008 22:10:20 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/192736 发表时间: 2008年05月13日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

08 年的前半年，祖国好像过的不怎么好，虽然我一直不关心国家大事，但耳闻的也是不少。闻知总理因地震之事一夜添了许些白发。心里很是感动。
自知现在还不能为祖国做点什么像样的贡献，只有默默工作，默默付出，努力学习。呵，是的，努力学习。
敬爱的祖国啊，全国的人们都在为你努力着，因你骄傲着。一直都是，永远都是。
08 年，祖国走好，我也会走好！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

设计模式之装饰（decorator）

zhouzhao21 — Wed, 07 May 2008 09:02:20 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/190460 发表时间: 2008年05月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

装饰模式（decorator pattern）：
装饰模式又名包装（Wrapper）模式。装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。
装饰模式以对客户端透明的方式动态地给一个对象附加上更多的责任。换言之，客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不使用创造更多子类的情况下，将对象的功能加以扩展。

装饰模式使用原来被装饰的类的一个子类的实例，把客户端的调用委派到被装饰类。装饰模式的关键在于这种扩展是完全透明的。

装饰模式中的各个角色：
抽象构件（Component）角色：给出一个抽象接口，以规范准备接收附加责任的对象。
具体构件（Concrete Component）角色：定义一个将要接收附加责任的类。
（抽象）装饰（Decorator）角色：持有一个构件对象的实例，并定义一个与抽象构件接口一致的接口。接口的实现方法值得注意，每一个实现的方法都委派给父类，但并不单纯地委派，而是有功能的增强。
by kyo：（抽象）装饰角色应不提供缺省的构造函数，以迫使子类调用其带参的构造函数并传入相应的具体组件对象。
具体装饰（Concrte Decorator）角色：负责给构件对象 “贴上” 附加的责任。每个具体装饰角色都实现规定的方法，在规定的方法中调用其父类的此方法并添加自己的附加代码。

装饰模式常常被称做包裹模式，就是因为每一个具体装饰类都将下一个具体装饰类或者具体构件类包裹起来。每一层包裹都提供了一些装的功能。(by kyo：怎么感觉和 AOP 的概念有点像...)

在以下情况下应当使用装饰模式：
1。需要扩展一个类的功能，或给一个类增加附加责任。
2。需要动态地给一个对象增加功能，这些功能可以再动态的撤销。
3。需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。
by kyo：装饰模式应该发尽量使用在无发生次序要求（无状态）的对象中。

使用装饰模式主要有以下优点：
1。装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。
装饰模式允许系统动态地决定“帖上”一个需要的“装饰”，或者除掉一个不需要的“装饰”。继承关系则不同，继承关系是静态的，它在系统运行前就决定了。
2。通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。而继承关系则没有这个优势，每一种不同的排列组合均需要事先通过子类的继承方式设计好。
3。使用装饰模式，可以比使用继承关系需要较少数目的类。使设计比较易于进行。但另一方面，使用装饰模式会产生比使用继承关系更多的的对象，比较难以控制（装饰模式的动态性较强）。
使用装饰模式主要的缺点：
这种比继承方式更加灵活机动的特性，意味着装饰模式比继承更加易于出错。

适配器模式的用意是要改变所考虑的对象的接口而不一定改变对象的性能（特性），而装饰模式的用意是要保持接口，从而增强所考虑对象的性能（特性）。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

设计模式之适配器

zhouzhao21 — Mon, 05 May 2008 07:57:05 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/189574 发表时间: 2008年05月05日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

适配器模式（ Adapter Pattern）把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。又称为转换器模式、变压器模式、包装（Wrapper）模式（把已有的一些类包装起来，使之能有满足需要的接口）。
模式所涉及的角色有：
目标（Target）角色：所期待得到的接口。
源（Adaptee）角色：需要适配的接口。
适配器（Adapter）角色：适配器把源接口转换成目标接口。根据这一角色的实现不同，可分为类的适配器模式（使用继承实现）和对象的适配器模式（使用委派关系实现）。

适配器模式的用意是将接口不同而功能相同或者相近的两个接口加以转换，包括适配器角色补充一些源角色没有但目标接口需要的方法。但不要误以为适配器模式就是为了补充源角色没有的方法而准备的。

类适配器模式与对象适配器模式的区别：
使用对象适配器模式可以把多种不同的源适配到同一个目标。换言之，同一个适配器可以把源类和它的子类都适配到目标接口。
使用对象适配器模式增加的新方法可以同时适用所有的源。
（对对象的适配器模式而言）在设计里，需要改变多个已有的子类的接口，如果使用类的适配器模式，就要针对每一个子类做一个适配器类，而这不太实际。
与类的适配器模式相比，要想置换源类的方法不容易。
如果源中有大量的方法，使用类的适配器模式则比较容易（不需要一一写出源类中的方法，而对象的适配器模式则要一一写出目标角色中的方法，如缺省适配器）。

在什么情况下使用适配器模式：
1。系统需要使用现有的类，而此类的接口不符合系统的需要。
2。想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。这些源类不一定有很复杂的接口。
3。类或方法的作用相同但名称不同的类或方法之间进行适配（by kyo）。

与桥梁模式的区别：
桥梁模式的用意是要把实现和它的接口分开，以便它们可以独立地变化。桥梁模式并不是用来把一个已有的对象接到不相匹配的接口上的。当一个客户端只知道一个特定的接口，但是又必须与具有不同接口的类打交道时，就应该使用适配器模式。

缺省适配模式（Default Adapter Pattern）为一个接口提供缺省实现，这样子类型可以从这个缺省实现进行扩展，而不必从原有接口进行扩展。

适配器模式的用意是要改变源的接口，以便与目标类的接口相容。缺省适配的用意稍有同，它是为了方便建立一个不平庸的适配器类而提供的一种平庸实现（就是为接口提供空的实现）。

在任何时候，如果不准备实现一个接口的所有方法时（一般在定义一个大的接口时都应该提供它的缺省适配类），就可以制造一个抽象类，给出所有方法的平庸的具体实现。这样，从这个抽象类再继承下去的子类就不必实现所有的方法了。缺省适配模式的中心是一个缺省适配类。这个类应当是抽象类。

在 JDK1.2 中有很多为事件处理而设计的事件监听适配器类。这些 Java 类均是为了使用的方便而提供的缺省适配器接口，它们为所对应的 Java 接口提供空的或称“平庸的(一般的)”实现。这样，Java 语言的用户程序如果需要实现一个接口中很少的几个方法时，就不必繁琐地给出它所不需要的那些方法的空的实现。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

代码自动生成和配置文件自动更改的工具

zhouzhao21 — Mon, 28 Apr 2008 07:51:41 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/187395 发表时间: 2008年04月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

程序功能是使用指定的模板文件生成或更改代码和配置文件。
具体的使用大家可以看附件。目前仅提供了 velocity 的实现，大家可以自己使用其他模板技术实现。
做的还不算太完善，比如对异常的友好提示方面，呵，做着就是给程序员们使用的。
欢迎大家提出宝贵意见。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

在 eclipse3.3 + myeclipse6 + tomcat6 环境下使用 appfuse

zhouzhao21 — Fri, 18 Apr 2008 13:46:54 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/184080 发表时间: 2008年04月18日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

在 eclipse3.3 + myeclipse6 + tomcat6 环境下使用 appfuse ：

Setup your Development Environment - or follow the steps below if you're a veteran.
1. Download and install JDK 5+ (make sure your JAVA_HOME environment variable points to the JDK, not a JRE).
2. Download and install MySQL 5.x.
(可选)3. Setup a local SMTP server or change mail.properties (in src/main/resources) to use a different host name - it defaults to "localhost".
4. Download and install Maven 2.0.x.

下载 appfuse 所需要的类库(appfuse-dependencies：https://appfuse.dev.java.net/servlets/ProjectDocumentList），修改%maven_home%/conf/settings.xml 文件中的 localRepository 节点
%appfuse-dependencies_home%
这样可节省项目生成时间，减少 moven 自网下下载类库的个数。
执行 mvn archetype:create 命令取相应的工程代码(参见 http://appfuse.org/display/APF/AppFuse+QuickStart )。注：-DgroupId 值为项目包的根路径，-DartifactId 为工程的名称。

在所建工程目录下执行 mvn appfuse:full-source 以获取完整的代码。
修改pom.xml，在最下面有数据库的配置。若你是mysql数据库，则很简单，只需修改用户名和密码（默认为root和空）。若是其他数据库，请参照pom.xml里面的数据库配置文件进行替换修改。
在所建工程目录下执行 mvn jetty:run-war 。这样会在target目录下生成部署需要的文件夹和war包(成功进行后打开 http://localhost:8080/ 可看到相应的界面)。
在项目路径下运行：mvn eclipse:eclipse 建立适合eclipse环境的工程。
将工程导入到 eclipse 中。
将 src/main/webapp Remove from build path 。
将target/classes Remove from build path 。
使用 myEclipse 的 Add MyEclipse Web Capabilities ，将 Web Root Directory 指向 src/main/webapp 目录。
将 target\%项目名称%-1.0-SNAPSHOT\WEB-INF\lib 目录下的类库 copy 到 src\main\webapp\WEB-INF\lib 目录下。
将 target\%项目名称%-1.0-SNAPSHOT\WEB-INF\classes 目录下的资源文件 copy 到 src\main\resources 目录下。
在 eclipse 中刷新项目。
在 java Build Path 中 Libraries 下面将以 M2_REPO 开头的 libs 删除。
在 eclipse 中使用 Package Explorer 打开 src/main/webapp/WEB-INF/lib ，如果其下还有库文件，则将其添加到 Build Path 。
在 eclipse 中刷新项目。

完成.

参考:
http://appfuse.org/display/APF/AppFuse+QuickStart
http://www.blogjava.net/shenlei/archive/2008/02/29/182885.html#FeedBack
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

设计模式之桥梁(Bridge)

zhouzhao21 — Fri, 11 Apr 2008 06:32:39 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/181531 发表时间: 2008年04月11日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

桥梁模式是对象的结构模式，又称柄体(Handle and Body)模式或接口(Interface)模式。
桥梁模式的用意是 "将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。
by kyo：抽象化有其单独的等级结构，实现化有其单独的等级结构，两者相不互干扰。
抽象化：存在于多个实体中共同的的概念性联系，就是抽象化。作为一个过程，抽象化就是忽略一些信息，从而把不同的实体当作同样的实体对待。
实现化：抽象化的具体实现，就是实现化，一个类的实例就是这个类的实现化，一个具体子类是它的抽象超类的实现化。
脱耦：所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的脱耦。
所谓强关联，就是在编译时期已经确定的，无法在运行时期动态改变的关联。所谓弱关联，就是可以动态地确定并且可以在运行时期动态地改变的关联。显然，在 Java 语言中，继承关系是强关联，而聚合关系是弱关联。
桥梁模式中所谓的脱耦，就是指一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是所谓的桥梁模式。

继承是一种强耦合，它在一开始便把抽象化角色和实现化角色的关系绑定(binding)，使得两个层次之间相互限制，无法独立的演化。

桥梁模式的角色：
抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同。实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
具体实现化(Concrete Implementor)角色：这个角色给出实现化角色接口的具体实现。
桥梁模式的等级结构：
由抽象化角色和修正抽象化本身组成的抽象化等级结构。
由实现化角色和具体实现化角色所组成的实现化等级结构。

一般而言，实现化角色中的每一个方法都应当有一个抽象化角色中的某个方法与之相对应，但是反过来则不一定。换言之，抽象化角色的接口比实现化角色的接口宽。抽象化角色除了提供与实现化角色相关的方法外，还有可能提供其他的商业方法；而实现化角色则往往仅为实现抽象化角色的相关行为而存在。
by kyo：抽象化角色不一定是抽象类。如修正抽象化角色有可能不是抽象类。

Java 为 AWT 中的每一个GUI 构件提供了一个 Peer 构件( by kyo：应该是每种操作系统一组 Peer 构件)，这个 Peer 构件是所属的 Java 构件在本地化环境中的实现化。在 Java 的 AWT 库中的每一个 Component 的子类都有一个 ComponentPeer 的子类与之匹配。所有 Component 的子类都属于一个等级结构，而所有的 ComponentPeer 的子类都属于另一个等级结构。Component 类型和 ComponentPeer 类型通过 Toolkit 对象相互通信。Component 相当于抽象角色，其子类如 Button 相当于修正抽象角色；ComponentPeer 相当于实现化角色，而 ButtonPeer 相当于具体实现化角色。系统根据当前操作系统动态地选择 Button 对象所使用的底层实现。Java 的 AWT 就是这样做到 "Write once , run anywhere " 的。

大多数的驱动器(Driver)都是桥梁模式的应用。使用驱动程序的应用系统就是抽象化角色，而驱动器本身扮演实现化角色。这使得应用程序与驱动器可以独立演化。如 JDBC 驱动器，一个应用系统动态地选择一个合适的驱动器，然后通过驱动器向数据库引擎发出指令。这个过程就是将抽象化角色的行为委派给实现角色的过程。

所谓重构，就是在不增加或减少一个软件系统的功能的情况下，对代码的结构进行优化。
所谓组合/聚合复用原则讲的是要尽量使用合成/聚合，而不是通过继承关系来达到扩展系统功能的目的。
使用桥梁模式的关键在于准确地找出系统的抽象化角色和具体化角色。 by kyo：分离抽象化与实现化。
"找到系统的可变因素，将之封装起来" ，通常就叫做 "对变化的封装"。
一般来说，一个继承结构中的第一层是抽象角色，封装了抽象的商业逻辑，这是系统中不变的部分。第二层是实现角色，封装了设计中会变化的因素。这个实现允许实现化角色有多态性变化。
桥梁模式将两个独立的等级结构封装在两个独立的变化因素中。抽象化和实现化的变化分别得到封装之后，使用聚合关系联系抽象化角色与实现化角色。以达到功能复用的目的。
从另一个角度讲，一个好的设计通常没有多于两层的继承等级结构。或者说，如果出现两个以上的变化因素，就需要找出哪一个是静态的，可以使用继承关系，哪一个是动态的，必须使用聚合关系。

桥梁模式和适配器模式的区别：
适配器模式的目的是要改变已有的接口，让它们可以相容，以使没有关系的两个类能在一起工作。而桥梁模式是分离抽象化和实现化，使得两者的接口可以不同。两个模式是向相反方向努力的。
区别类图相似而本质不同的设计模式的关键是比较两者的用意：一个模式被设计出来要解决的问题，便是此模式的用意。
桥梁模式和状态模式的关系：
桥梁模式描述两个等级结构之间的关系，状态模式则描述一个对象与其(外部化的)状态对象之间的关系。状态对象可以看做是桥梁模式的一个退化后的特殊情况。

在什么情况下应当使用桥梁模式：
如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

一个图像格式有两个基本的方面，一是结构，二是表象。其结构决定图像是怎样存储的，而其表象决定了图像是怎样显示在屏幕上的。对于一个图像格式来说，其结构是在任何一种操作系统中都不变的(但不同格式的图像有不同的结构)，而其表象是在每个操作系统中都有所不同的(不同的操作系统有不同的表象)。图像的结构和表现是两个不同的方面，应该让它们独立地变化，桥梁模式正好可以在这里发挥作用。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

我是如何节约时间的

zhouzhao21 — Thu, 10 Apr 2008 09:02:20 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/181082 发表时间: 2008年04月10日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我努力享受自己正在做的任何事情。
我不会浪费时间为过去的失败感到遗憾。
我不会浪费时间为那些自己没做的事情感到羞愧。
如果一件事情真的很重要的话，我总能找到时间完成它。
读书的时候，我只会用很少时间，只了解书的要点内容。
我没有电视机。
我的办公室跟我的住所距离很近，所以我可以走路去上班。只有在遇到急事的时候，我才会开车。
我会反思自己的旧习惯，并尽量改掉那些不好的习惯。
我放弃所有的 "等待时间"。如果我不得不等待的时候，我将其看成是放松自我的机会，或者我也可以利用这段时间来做一些我平时不会做的事情。
我的手表比标准时间快三分钟，这样我每天都可以比别人提前三分钟。
我会在口袋里放一些卡片，以便记录下随时想出来的好点子。
我每个月重新修改一下自己的人生目标。
即便是在做一些最不起眼的工作的时候，我都会想着自己的长期目标。
我起床后的第一件事情就是规划，并把当天要做的事情安排好先后次序。
我会首先做重要的事情。
我告诉自己更加聪明而不是更加辛苦地工作。
我会问自己，"如果我不做这件事情的话，是否会出现极其严重的后果呢？" 如果答案是否定的话，我就会取消这件任务。
我感觉自己有些想拖拉的话，我会问自己，"你到底在逃避什么？" 然后我会直接面对可能出现的问题。
在开始一个大型项目的时候，我会首先从那些最重要的部分开始，并经常发现其他部分其实并不重要。
我给自己足够的时间来完成那些重要的工作。
我已经具备了长时间集中精力的能力。
我一次只集中精力处理一件事情。
我集中精力处理那些能够带来长期收益的事情。
我总是不断努力，并坚信自己会取得成功。
我会把自己的大部分想法记录下来。
我会为自己和其他人设定最后期限。
我在每次跟人讨论的时候都会积极聆听。
我尽量不浪费其他人的时间(除非是一些对我真正重要的事情)。
我尽量把一些事情委托给他人完成。
我会请专家来帮助我完成一些专业性的问题。
我会请人帮我筛选邮件和电话，并帮助我处理所有常规性工作。
每份文件我只处理一次。
我周末的时候尽量不考虑工作。
我经常让自己放松，什么都不做。
我意识到迟早有一天，我会用一些时间来应付一些自己无法控制的事情，我不会为此感到厌烦。
我总是准备采取行动来进一步实现我的人生目标。
我总是不断问自己，"我现在最应该做什么事情？"
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

设计模式之门面(Facade)

zhouzhao21 — Wed, 09 Apr 2008 07:39:19 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/180672 发表时间: 2008年04月09日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

外部与一个子系统的通信必须通过一个统一的门面(Facade)对象进行，这就是门面模式。

设计模式的任务就是协助设计师处理复杂系统的设计。设计师处理复杂系统的一个常见方法便是将其 "分而治之" ，把一个系统划分为几个较小的子系统。

门面模式要求一个子系统的外部与其内部的通信必须通过一个统一的门面(Facade)对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。

门面模式中的角色：
门面(Facade)角色：客户端可以调用这个角色的方法。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。
子系统(Subsystem)角色：每一个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另一个客户端而已。

在门面模式中，通常只需要一个门面类，并且此门面类只有一个实例，换言之它是一个单例类。但如果一个系统有好几个子系统的话，每个子系统都可有一个门面类，整个系统可以有数个门面类。
如果一个门面模式不能将子系统的所有行为提供给外界，那么可以通过修改或继承门面类的方法将子系统的行为提供给外界。但是，如果一个子系统没有某个行为，想通过修改或继承门面类的办法来提供这个新的行为是错误的。

在什么情况下使用门面模式：
为一个复杂子系统提供一个简单接口：子系统往往因为不断演化而变得越来越复杂，使用门面模式可以使得子系统更具有可复用性。
子系统的独立性：引入门面模式将一个子系统与它的客户端以及其他子系统分离，可以提高子系统的独立性和可移植性。
层次化结构：在构建一个层次化的系统时，可以使用 Facade 模式定义系统中每一层的入口。如果层与层之间是相互依赖的，则可以限定它们仅通过 Facade 进行通信，从而简化层与层之间的依赖关系。
迪米特法则说："只与你直接的朋友们通信" 。迪米特法则要求每一个对象与其他对象的相互作用均是短程的，而不是长程的。只要可能，朋友的数目越少越好。换言之，一个对象只应当知道它的直接合作者的接口。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

设计模式之代理(利用间接通信改善系统设计的模式)

zhouzhao21 — Tue, 08 Apr 2008 08:28:28 +0800

作者: zhouzhao21 链接：http://kyocc.javaeye.com/blog/180323 发表时间: 2008年04月08日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

代理模式(利用间接通信改善系统设计的模式)：
代理模式给某一对象提供一个代理对象，并由代理对象控制对原对象的引用。
间接性的通信可以给出较低的耦合关系，较强的合作关系，以及微妙的结构和易于复用的设计架构。
所谓代理(proxy or surrogate)，就是一个人或者一个机构代表另一个人或者另一个机构采取行动。在一些情况下，一个客户不想或者不能够直接引用一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。
如果按照使用目的来划分，代理有以下几种：
远程(Remote)代理：
虚拟(Virtual)代理：
Copy-on-Write 代理：
保护(Protect or Access)代理：
Cache 代理：
防火墙(firewall)代理：
同步化(Synchronization)代理：
智能引用(Smart Reference)代理：
代理模式所涉及的角色有：
抽象主题角色：声明了真实主题和代理主题的共同接口，这样一来在任何可以使用真实主题的地方都可以使用代理主题。
代理主题角色：代理主题角色内部含有对真实主题的引用，从而可以在任何时候操作真实主题对象，代理主题角色内部含有对真实主题角色相同的接口，以便可以在任何时候都可以替代真实主题。
真实主题角色：代理角色所代表的真实对象。
代理模式是怎样工作的：
首先，代理主题并不改变主题的接口，因为模式的用意是不让客户端感觉到代理的存在。
其次，代理使用委派将客户端的调用委派给真实的主题对象，换言之，代理主题起到的是一个传递请求的作用。
最后，代理主题在传递请求这前和之后都可以执行特定的操作，而不是单纯传递请求。
代理模式将一个中间层插入到客户端和主题角色之间，从而提供了许多的灵活性。

Java 语言通过 java.lang.reflect 库中提供了三个类直接支持代理模式：Proxy 、InvocationHandler 和 Method 。其中 Proxy 类使得设计师能够在运行时间创建代理对象。
设计师创建动态代理的步骤：
1。指明一系列的接口来创建一个代理对象。
2。创建一个调用处理器(Invocation Handler)对象。
3。将这个代理指定为某个其他对象的代理对象。
4。在调用处理器的 invoke() 方法中采用代理，一方面将调用传递给真实对象，另一方面执行各种需要做的操作。

代理模式与其它模式的关系：
适配器模式：适配器模式的用意是要改变所考虑的对象的接口，而代理模式并不能改变所代理的对象的接口，在这一点上两个模式有明显的区别。
装饰模式：装饰模式应当为所装饰的对象提供增强功能；而代理模式对对象的使用施加控制，并不提供对象本身的增强功能。
门面模式：有时候，门面模式兼任代理的责任，这种时候的门面模式又叫代理门面模式，或门面代理模式。

不同种类的代理：
远程代理：
优点是系统可以将网络的细节隐藏起来，使得客户端不必考虑网络的存在。缺点是由于客户可能没有意识到会启动一个耗费时间的远程调用，因此，客户没有必要的思想准备。
虚拟代理：
优点是代理对象可以在必要的时候才将被代理的对象加载。代理可以对加载的过程加以必要的优化。当一个模块的加载十分耗费资源的时候，虚拟代理的优点就非常明显。
当一个真实主题对象的加载需要耗费资源时，一个虚拟代理对象可以代替真实对象接受请求。一旦接到请求，代理对象马上打出一段 "正在加载" 的信息，并在适当的时候加载真实主题对象，也就是模块等资源。
保护代理：
优点是它可以在运行时间对用户的有关权限进行检查，在核实后决定是否将调用传递给被代理的对象。
智能引用代理：
在访问一个对象时可以执行一些内务(Housekeeping)处理操作，如计数操作等。

有经验的设计师不会仅仅给出一个具体类就交差，因为设计师必须考虑到查询功能在今后可能会有的变化。因此，一个好的设计必须使系统可以在最小的改动下进行最大的扩充。
代理模式的用意之一，要针对抽象编程，不要针对具体编程。

SwingUtilities.invokeLater() 方法会开启一个独立的新线程，用以执行一个新的任务(异步执行)。SwingUtilities.invokeAndWait() 方法与前者不同的是，它会将主线程的执行封锁住，直到新线程的任务完成为止(同步执行)。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐