PureMVC(AS3)剖析:设计模式(二)

PureMVC(AS3)剖析:设计模式(二)


模式

上一篇中介绍了PureMVC中使用的3种设计模式:单例模式、观察者模式、外观模式。本篇将继续介绍剩下的3种设计模式:

l  使用中介者(Mediator)模式来封装UI与系统中其他对象的交互,使得各对象不需要显示地互相引用,从而使得其耦合松散,而且可以独立地改变它们之间的交互;

l  使用代理(Proxy)模式为数据对象提供代理以控制数据对象的访问,PureMVC中Proxy负责操作数据模型,与远程服务信存取数据;

l  使用命令(Command)模式将请求封装为一个对象,实现“行为请求者”与“行为实现者”解耦将发出命令的责任和执行命令的责任分割开。

1.  中介者模式

中介者(Mediator)模式:用一个中介对象来封装一系列对象交互。中介者使各对象不需要相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。适用性:(摘自:《设计模式:可复用面向对象软件的基础》)

l  一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。

l  一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。

l  想定制一个分布在多个类中的行为,而又不想生成太多的子类。

在PureMVC中,Mediator帮助我们创建或重用已有UI组件,而UI不用知道PureMVC框架相关的东西,UI仅用于显示数据、接收用户输入。Mediator是UI组件与框架的中介,它负责将来自PureMVC框架的消息转接到UI,并将UI的消息(flash事件)转发广播到PureMVC框架。这样通过Mediator解耦了UI与PureMVC框架元素(Proxy、Mediator、Command),而不用互相引用。

图:中介者模式

一个Mediator只与一个UI绑定(1对1),Mediator构造函数参数传递与之绑定的UI。通过façade的registerMediator方法注册Mediator,以接收PureMVC框架的通知(通过上篇介绍的外观模式,可以知道其实最终是通过View这个单例来注册的,façade只是提供接口)。

图:Mediator与UI的关系

2.  代理模式

代理(Proxy)模式:为其它的对象提供一种代理,以控制对这个对象的访问。按照使用目的来划分,代理有以下几种:(摘自:《设计模式:可复用面向对象软件的基础》)

l  远程(Remote)代理:为一个位于不同的地址空间的对象提供一个局域代表对象。这个不同的地址空间可以是在本机器中,也可是在另一台机器中。远程代理又叫做大使(Ambassador)。

l  虚拟(Virtual)代理:根据需要创建一个资源消耗较大的对象,使得此对象只在需要时才会被真正创建。

l  Copy-on-Write代理:虚拟代理的一种。把复制(克隆)拖延到只有在客户端需要时,才真正采取行动。

l  保护(Protect or Access)代理:控制对一个对象的访问,如果需要,可以给不同的用户提供不同级别的使用权限。

l  Cache代理:为某一个目标操作的结果提供临时的存储空间,以便多个客户端可以共享这些结果。

l  防火墙(Firewall)代理:保护目标,不让恶意用户接近。

l  同步化(Synchronization)代理:使几个用户能够同时使用一个对象而没有冲突。

l  智能引用(Smart Reference)代理:当一个对象被引用时,提供一些额外的操作,比如将对此对象调用的次数记录下来等。

在所有种类的代理模式中,虚拟(Virtual)代理、远程(Remote)代理、智能引用代理(Smart Reference Proxy)和保护(Protect or Access)代理是最为常见的代理模式。

在PureMVC中,Proxy帮助我们以更易于重用、修改对应用程序影响最小的方式暴露数据结构、接口给应用程序。Proxy可能只是简单的管理本地数据对象,以同步方式获取或修改数据;也可能是远程服务器数据,以异步方式操作数据,服务器数据返回之后以Notification方式告诉应用程序。

总之,Proxy 集中程序的Domain Logic(域逻辑),并对外公布操作数据对象的 API。它封装了所有对数据模型的操作,不管数据是客户端还是服务器端的,对程序其他部分来说就是数据的访问是同步还是异步的。

图:Proxy模式

3.  命令模式

命令(Command)模式:又称为行动(Action)模式或交易(Transaction)模式,命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能。(摘自:《设计模式:可复用面向对象软件的基础》)

命令模式是对命令的封装,把发出命令的责任执行命令的责任
割开,委派给不同的对象。每一个命令都是一个操作:请求的一方发出请求要求执行一个操作;接收的一方收到请求,并执行操作。命令模式允许请求的一方和接收
的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否被执行、何时被执行,以及是怎么被执行的。

图:PureMVC中命令执行时序

在PureMVC中,命令用来检索、操作Proxy,或者与Mediator通信,或者执行其它命令(符合命令)。命令有两种:SimpleCommand、MacroCommand,分别用于执行单个任务、多个任务。MacroCommand可以顺序其实多个SimpleCommand。

图:简单命令与复合命令

命令模式优点:(http://baike.baidu.com/view/1963264.htm

l  降低对象之间的耦合度。

l  新的命令可以很容易地加入到系统中。

l  可以比较容易地设计一个组合命令。

l  调用同一方法实现不同的功能

命令模式缺点:

使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个命令都需要设计一个具体命令类,因此系统可能需要大量具体命令类,这将影响命令模式的使用。

时间: 2024-09-19 10:09:53

PureMVC(AS3)剖析:设计模式(二)的相关文章

x264代码剖析(二):如何编译运行x264以及x264代码基本框架

x264代码剖析(二):如何编译运行x264以及x264代码基本框架           x264工程在x265出现之前一直在更新,但是自x264-20091007(含)不再支持VC++平台,也就是说支持VC++平台的x264的最新版本是x264-20091006.接下来就以该版本为例简单介绍如何编译运行x264以及x264代码的基本框架.           首先下载x264-20091006,地址为:http://ftp.videolan.org/pub/videolan/x264/snap

AS3日积月累之二:从AS1和AS2到AS3的观念转变

http://as3blog.com/as3/as3tip-new-philosophy/ AS1/2-AS3观念的转变(Meet with new philosophy)对于AS1.AS2的开发模式来说,灵活是最大的优势.然而,灵活却造成了不稳定.紊乱.这是开发复杂的.长久的项目所忌讳的.关于(AS1/2/1+2)灵活轻便与稳定持久(AS3)的权衡,我个人觉得可以理解为"鱼和熊掌不可兼得",但我希望已经习惯了AS1.AS2的朋友们不要把这个结论想得太悲观. AS3是纯粹面向对象的,相

WCF技术剖析之二十七: 如何将一个服务发布成WSDL

[基于WS-MEX的实现](提供模拟程序) 通过<如何将一个服务发布成WSDL[编程篇]>的介绍我们知道了如何可以通过编程或者配置的方式将ServiceMetadataBehavior这样一个服务形式应用到相应的服务上面,从而实现基于HTTP-GET或者WS-MEX的元数据发布机制.那么在WCF内部具体的实现原理又是怎样的呢?相信很多人对此都心存好奇,本篇文章的内容将围绕着这个主题展开. 一. 从WCF分发体系谈起 如果读者想对WCF内部的元数据发布机制的实现原理有一个全面而深入的了解,必须对

WCF技术剖析之二十六:如何导出WCF服务的元数据(Metadata)[扩展篇]

通过<实现篇>对WSDL元素和终结点三要素的之间的匹配关系的介绍,我们知道了WSDL的Binding元素来源于终结点的绑定对象,那么这些基于Binding的元数据以及相应的策略断言是如何被写入WSDL的呢?WSDL导出扩展(WSDL Export Extension)和策略导出扩展(Policy Export Extension)就是为此设计的. 一.WSDL导出扩展(WSDL Export Extension) 终结点的绑定本质上就是相关的绑定元素(BindingElement)的有序组合(

WCF技术剖析之二十四:ServiceDebugBehavior服务行为是如何实现异常的传播的?

服务端只有抛出FaultException异常才能被正常地序列化成Fault消息,并实现向客户端传播.对于一般的异常(比如执行Divide操作抛出的DivideByZeroException),在默认的情况下,异常信息无法实现向客户端传递.但是,倘若为某个服务应用了ServiceDebugBehavior这么一个服务行为,并开启了IncludeExceptionDetailInFaults开关,异常信息将会原封不动地传播到客户端.WCF内部是如何处理抛出的非FaultException异常的呢?

WCF技术剖析之二十一:WCF基本异常处理模式[下篇]

从FaultContractAttribute的定义我们可以看出,该特性可以在同一个目标对象上面多次应用(AllowMultiple = true).这也很好理解:对于同一个服务操作,可能具有不同的异常场景,在不同的情况下,需要抛出不同的异常. 1: [AttributeUsage(AttributeTargets.Method, AllowMultiple = true, Inherited = false)] 2: public sealed class FaultContractAttri

设计模式(二):自己动手使用“观察者模式”实现通知机制

在之前发布Objective-C系列博客的时候,其中提到过OC的通知机制,请参考<Objective-C中的老板是这样发通知的(Notification)>这篇博客.在之前关于Notification的博客中,只介绍了Foundation框架中的通知的使用方式.正如前面博客中提到的那样,通知是"一对多的关系",类似于广播.一个人发通知,多个人接收.这也就是设计模式中的"观察者模式".接收者的一方是Observer(观察者),而发送方是Subject(主题

WCF技术剖析之二十三:服务实例(Service Instance)生命周期如何控制[下篇]

在[第2篇]中,我们深入剖析了单调(PerCall)模式下WCF对服务实例生命周期的控制,现在我们来讨轮另一种极端的服务实例上下文模式:单例(Single)模式.在单例模式下,WCF通过创建一个唯一的服务实例来处理所有的客户端服务调用请求.这是一个极端的服务实例激活方式,由于服务实例的唯一性,所有客户端每次调用的状态能够被保存下来,但是当前的状态是所有客户端作用于服务实例的结果,而不能反映出具体某个客户端多次调用后的状态.WCF是一个典型的多线程的通信框架,对并发的服务调用请求是最基本的能力和要

WCF技术剖析之二十七: 如何将一个服务发布成WSDL[基于WS-MEX的实现](提供模拟程序)

通过<如何将一个服务发布成WSDL[编程篇]>的介绍我们知道了如何可以通过编程或者配置的方式将ServiceMetadataBehavior这样一个服务形式应用到相应的服务上面,从而实现基于HTTP-GET或者WS-MEX的元数据发布机制.那么在WCF内部具体的实现原理又是怎样的呢?相信很多人对此都心存好奇,本篇文章的内容将围绕着这个主题展开. 一. 从WCF分发体系谈起 如果读者想对WCF内部的元数据发布机制的实现原理有一个全面而深入的了解,必须对WCF服务端的分发体系有一个清晰的认识.在这

Linux Framebuffer驱动剖析之二—驱动框架、接口实现和使用

本文继上一篇文章<Linux Framebuffer驱动剖析之一-软件需求>,深入分析LinuxFramebuffer子系统的驱动框架.接口实现和使用. 一.LinuxFramebuffer的软件需求 上一篇文章详细阐述了LinuxFramebuffer的软件需求(请先理解第一篇文章再来阅读本篇文章),总结如下: 1. 针对SOC的LCD控制寄存器进行编程,以支持不同的LCD屏,以使该SOC的应用场景最大化.这是硬件平台相关的需求.其对应Linux源码路径arch\arm\mach-s5pv2