SRP(Single Responsible Principle), 单一职责原则，这是面对的最基本原则，也是实现弹性设计的最基本原则。

每个类或接口定义应该只包含一种明确的职责，同时仅有一种原因会导致这种定义的修改。一个复杂的类或接口的定义包含多个责任，很容易使你的设计失去弹性，很多因素都会导致这个类或接口的变更，由于它含有多种职责，这就意味着它是多种服务的提供者，会有多种依赖于它的客户类，他的变更可能会导致大范围的变更。

在作者看来，优先级最高的是你首先要保证接口的单一职责及方法的单一职责，接口通常意味可以更换不同的实现，为一个接口定义过多的职责意味着每个实现都会涉及多个职责，这将导致无法实现更小粒度的实现的复用。

2 面向抽象编成

如果你已经读过GOF的《设计模式》，你便知道其中每一个模式都是基于此原则的，抽象（或接口）有效的解除了服务调用者和服务提供者间的耦合。

3 使用配置

通过修改配置文件便可以改变系统的某些特性，这种修改的区别于修改代码，对于Java,C++而言这种修改是不需要编译，有的修改甚至可以在运行时生效。DSL地运用可以使配置更加具有可读性及更强的描述能力。在设计时将实现分为配置及框架部分是非常灵活的结构。

蔡超
HP 软件架构师
软件架构顾问
SCEA
IBM Certified Solution Designer for OOA&D vUML2
Chaocai2001@yahoo.com.cn

在OO中可以使用抽象方法及接口来完成文中通过函数指针和结构体来实现的间接层。

Client.java

AppInterface app=new AppImpl();

AppInterface app1=new AppProxy(app);

AppProxy.java

public class AppProxy implements AppInterface{

               private AppInterface appRef;

               public AppProxy(AppInterface appRef){

                              this.appRef=appRef

               }

public void doSomething(){

               /*some codes*/

}

}

通过Proxy来实现间接层，相互嵌套可以实现多个间接层，并且可以通过一个AppBuilder来创建这个对象，组合多个间接层。间接层中可以实现文中提及的对参数的预处理。

同时，我也认为文中提及的间接层也可以是Adapter。

1 根据对象来选择行为问题

public interface Event {

}

public class BlueEvent implements Event {

}

public class RedEvent implements Event {

}

public class Handler {

public void handle(Event event){

System.out.println("It is event");

}

public void handle(RedEvent event){

System.out.println("It is RedEvent");

}

public void handle(BlueEvent event){

System.out.println("It is BlueEvent");

}

}

public class Main {

public static void main(String[] args) {

Event evt=new BlueEvent();

new Handler().handle(evt);

}

}

你认为运行结果是什么呢？

结果：It is event

是不是有点出乎意料，不是It is BlueEvent，这是应为Overload并不支持在运行时根据参数的运行时类型来帮定方法，所以要执行哪个方法是在编译时就选定了的。

2 Double Dispatch Pattern

由于Java,C++及C#都具有上述局限，通常我们只能通过Switch或if结构来实现，当然这种实现方式既不优雅而且影响代码的可维护性。

通过以下的Double Dispatch Pattern便可以优雅的实现。

public interface Event {

public void injectHandler(EventHandler v);

}

public class BlueEvent implements Event {

public void injectHandler(EventHandler v) {

v.handle(this);

}

}

public class RedEvent implements Event {

public void injectHandler(EventHandler v) {

v.handle(this);

}

}

public class EventHandler {

public void handle(BlueEvent e){

System.out.println("It is BlueEvent");

}

public void handle(RedEvent e){

System.out.println("It is RedEvent");

}

}

public class Main {

public static void main(String[] args) {

Event evt=new BlueEvent();

evt.injectHandler(new EventHandler());

}

}

其实设计模式（GoF)中的Visitor模式就是Double Dispatch的一种应用。


蔡超
HP 软件架构师
软件架构顾问
SCEA,SCBCD,MCSD
IBM Certified Solution Designer for OOA&D vUML2
Chaocai2001@yahoo.com.cn,chao.cai@hp.com

首先我们分析OSGi的特点及可以给我们应用带来的好处

1 良好的动态特性

2 更细粒度的类装载控制，多个版本组件在同一运行环境中共同运行

3 在JVM内部实现SOA（我个人倒是认为OSGi所涉及的仅仅是SOA思想的一小部分）

4 DS提供的IoC支持

请思考你的应用程序真的需要这些吗？

很多设计和开发人员都会在设计和实现时忽略应用的真正需要和OSGi的复杂性，将应用的所有内部细小划分都采用Bundle实现。

而我们除了应该注意采用OSGi开发和调试带来的复杂性；同时也要明白动态特性的支持并不是仅仅采用OSGi平台就可以搞定的，要真正实现动态特性必须注意模块的启动顺序无关性及对其所依赖服务的监听等，这些都会大大增加系统实现和调试的复杂性。

其实我们应该认真分析应用是否需要这些OSGi的特性及这些特性应该在应用的那些部分体现，例如我们可以在扩展方面采用Bundle实现扩展插件，至于其它部分则不必采用过多的Bundles（甚至可以采用一个大的Bundle，而其内部则可以采用如Spring来帮助我们实现模块化）。

同时，不要忘记其他的framework同样提供了很好的组件化的基础架构如Spring，Pico-Container，在OSGi与其它技术混合时SCA同样是很好的选择。

保持应用的简单性，不要针对特定技术进行设计，而要为设计选择适合的技术。

蔡超
Chaocai2001@yahoo.com.cn

因此大家在设计过程中不要仅仅将分层结构留于形式，而要时刻注意设计是否符合这种架构模式，这样才能真正发挥这种架构模式的优势。

北京天融信，软件架构师

SUN certified Enterprise Architect

Microsoft certified Solution Developer

IBM certified RUP Specialist

联系方式 :cai_chao@topsec.com.cn,chaocai2001@yahoo.com.cn

010-82776427

语境

在基于异步通信方式的系统中，实现模块的同步调用。

问题

消息队列已经成为目前很多软件选用的通讯方式，消息模式使得不同分布式组件间的耦合性较为松散，提高了系统的可维护性和可扩充性。但是有时我们希望在这种情况下能够模拟同步的调用方式，希望能够通过一个组件透明的帮我们实现这种异步和同步调用的转换。

解决方案

图表 1 基于消息的分布式系统

上图是一种常见的基于消息的分布系统结构，系统中包含两条队列。命令队列用于传送模块间相互调用的命令对象，响应队列用于传送命令处理后的响应结果对象。

在通常情况下消息队列上的模块会以异步的方式工作，这种情况下模块通常不关心命令执行后的状况，常常是不须返回值的。

为了模拟同步调用我们通过一个 SynProxy 组件来帮助我们完成由异步到同步调用的模拟。使得 Client 对其他模块的调好像是同步的一样。

SynProxy 组件的结构如下：

图表 2 SynProxy 的静态结构

SynProxy: 组织完成异步到同步调用的转换

WaitingQueue: 存放还未获得执行返回值的 Command 对象

UIDCreator: 产生能够唯一标示每个 Command 对象的 UID

ResponseReceiver: 监听响应队列中的响应消息，它在独立的线程中运行

Command ：命令对象

Response ：响应对象

图表 3 将异同步调用转化成同步调用的过程

部分解释： ( 以上以在 JAVA 环境中为例 )

Wait 表示调用 Command 的 wait 方法阻塞住当前线程

Command 执行模块在执行了响应操作后生产 Response 对象用于放回结果， Response 对象中的 UID 属性应该与处理的 Command 的 UID 的值相同

Notify 表示调用 Command 的 notify 方法唤醒被阻塞的线程

上面过程中的 wait 设置了阻塞的超时时间（来自于 Command 对象的属性值）

SCEA ， SCBCD ， MCSD
北京天融信软件架构师
 SUN,Microsoft培训中心特邀高端教师

常年提供架构咨询服务

chaocai2001@yahoo.com.cn ， 010-82776427

4+1 视图与 UML

软件架构设计已经逐渐成为现代软件开发过程的核心，然而能够清晰表明架构设计并不是一件容易的事，就面向对象开发而言， RUP 的 4+1 视图已在架构设计的撰写中得到了广泛的应用和认可。

对于 4+1 view 的描述有几个不同版本（或包含的视图不同，或视图的名称不同），文中以 Philippe Kruchten, November 1995 提出的 4+1 视图为准。

4+1 视图包括：逻辑视图（ Logic View ），开发视图（ Develop View ），进程视图（ Process View ），物理视图（ Physical View ）和场景视图（ Scenarios ）。

视图间的关系

4+1 视图不仅便于我们记录架构设计，实际上它也指导了我们进行架构设计活动的部分过程。

通常我们选择 UML 来表现各种视图，以下列出了 UML 和各视图的对应关系

4+1 视图                                    UML

场景视图                             use case

逻辑视图                             类图

开发视图                             类图，组件图

进程视图                             无完全对应

部署视图                             部署图

在架构设计稳定中通常不会给出较多的用例描述，这些是在需求稳定中定义。但是往往架构文档会选择一些用例，列入文档中，这些用例和一些非功能性需求一起用以证明架构的有效和正确性。在逻辑视图中用例的实现是必不可少的一节，尽管架构设计更关注非功能性需求。

融入 MDA 的思想

对于逻辑视图和开发视图所应包含的内容常常会觉得很难区分两者间的明显界限。逻辑视图包含更多的分析模型与实现技术本身相关性应该较少，如业务对象模型及其扩展。而开发视图则会与实现技术紧密相关。

随着 MDA 思想的推广，在架构设计文档的撰写方面也产生了影响，我们不难把 MDA 的 PIM 和逻辑视图联系起来，而把 MDA 中的 PSM 和开发视图联系起来。

在编写逻辑视图是我们应该描述与技术平台无关的模型，而开发视图则描述与实现技术平台相关的模型。

如在逻辑视图中表现的某些实体类，我们会在开发视图中转换为 EJB 组件（实体 Bean ）。

这种做法不仅有利于我们编写架构设计文档，同时更是一种好的架构设计思考流程。

蔡超

1         MVC 简介

一般应用中用户界面的变化相对较为频繁 , 有时需要支持多种表现模式（如 WEB 客户端和 GUI 客户端），但是数据和业务逻辑相对保持稳定。

MVC(Model-View-Controller) 模式是一种常用的设计模式 ,MVC 将模型 , 显示和控制进行了分离，可以使得应用更加方便实现对多种表现模式的支持及降低表现形式修改对整体系统的影响。由于本文重点讨论的是 MVC 中的通知机制，至于 MVC 的其它内容可以参考其它相关文档。

图表 1 MVC 模式

2         MVC 的通知机制

上图是在 SUN 的 J2EE BluePrints 中关于 MVC 模式的描述 , 在实现 MVC 模式时首先应该注意的是模型与视图之间的关系。在这些关系中尤其值得大家注意的是模型通知视图，如果不能正确的设计这个通知机制（模型与视图之间关联实现通知）便会完全违背 MVC 的设计初衷。 MVC 模式的其中一个目的在于使模式独立与视图，然而不正确的理解和设计通知机制会导致模型和试图的依赖性。

2.1     采用 Observer 模式实现通知机制

既要实现模式到视图的通知机制，同时有要确保实现模型与视图的分离。通常我们可以通过Observer模式来实现这样的通知机制。

图表2 Observer模式

视图实现 Observer 接口，并向模型注册，模型通过调用所维护的观察者的实例调用 Update 方法来通知视图进行刷新。可见， Observer 接口有效的实现了模型和视图间的耦合性的分离。

2.2     模型通知视图还是控制器通知视图

图表 3 基于 MVC 的 J2EE 应用

在将 MVC 模式应用于的总体结构时，常常会有是模型通知视图还是控制器通知视图的问题，其实我认为这个问题完全取决于对系统各个部分的划分和理解，如果我们把模型层更多划分为数据实体 ( 如： Entity Bean) 则可能会发现，其实我们的通知机制是不能由模型部分来完成的，而是由我们的控制器来完成的。这种划分好象有些违背了 MVC 模式，但实事上特别是一些想要同时支持 B/S 和 C/S 的 J2EE 应用，控制器和模式通知机制常常有较大的耦合性（ C/S 结构中，客户完全通过会话 Bean 来完成业务），可能有时在一起实现更好。

总之，更好的内聚性和更松散的耦合性才是架构设计的重点，应该做出适合自身应用的 MVC 架构。

3         结束语

MVC 模式的关键在于分离易变和不易变部分间的耦合性，所以在应用 MVC 模式时一定要注意解耦才是关键，同时一定要更据具体的使用环境进行调整，不要生搬硬套，如 Microsoft 的 MFC 采用的 Document-view 就是 MVC 的变体，它把控制器合并到视图中，这是因为考虑了视图与控制器紧耦合的影响。

【参考文献】

1．  Sun Microsystem ， J2EE BluePrints

2．  GOF,Design Patterns, 机械工业出版社， 2002

作者： 蔡超