ActionScript3设计模式完整版

ActionScript3设计模式模型/视图/控制器模式M-数据模型。用以存储数据的空间，它与视图和控制器是分离开来的。模型应该不能直接引用视图或者控制器。说白了，就是专门用以存储数据，或者说只保有属性，几乎没有方法（getter、setter除外）。而为了保持良好的封装性，属性均由getter和setter方法来与外界通信。对于数据读写的一些限制或者要求一般会在getter、setter方法里完成。模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。V-视图。既用户界面系统的显示部分，简单的说，用户看得见的东西均属于视图部分。视图通过调用数据模型来绘制外观，视图通过各种可视的方法把数据呈现与用户。注意，视图仅仅有可视元素组成，但是可以读取模型的数据以所需要的方式呈现。视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和\o"查看图片"

MVC模式Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。C-控制器。在需要的时候获取输入（用户交互或者系统通信）以及更新数据和视图信息。控制器主要是用来更新数据以及控制视图位置以及显示与否等（既相当于控制视图的整体，而不控制视图中由数据影响的部分，该部分由数据变化后自行对数据变化做出反应）。控制(Controller)可以理解为从用户接收请求,将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后,并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。mvc是一个复合模式

mv，mc都是观察者模式

m内部的组件组合模式

vc之间是策略模式(可以随时更换不同的控制器)

三者的联系。模型应当一直与视图和控制器保持独立。也就是说，模型不关心视图和控制器，模型的数据发生更改将会通过广播的形式通知视图和控制器。视图则一直关心着模型的状态，既时刻侦听模型所发出的事件，并及时更新自己。而控制器也一直关注模型的所有状态，在适当的时候根据用户输入和系统事件来更新模型。控制器和视图是紧密耦合的。视图内部可以完成的逻辑写于视图内部。而对于模型数据的更改，以及视图与视图之间的交互则交与控制器完成。个人认为控制器就像是包裹在一个视图组外面，它控制着这几个视图之间怎么交互，而视图里面又可以嵌套一个这样的结构，一层套一层。就像一个村里，村长管理着这家人干什么，那家人干什么，而这每一家人中的当家又管理着家里的每个人各自应当干什么（控制器控制视图），而所谓视图内部则是指村长不会管你每户人家里是怎么分配完成任务的，而当家的也不会管你个人的吃喝拉撒。而村长和当家都会把一些重要信息，例如账，记到账本里（控制器改变数据），这个账本就像数据模型，都是些数据，它只会告诉人们，现在财务什么状况了，但是它不会管你是不是吃饱了挨饿了（模型独立性）。村长写的账本告诉每家每户村里什么情况了，当家写的账本告诉家里的人家里什么状况了。家里的人可以通过有没吃饱穿暖来表现当家写的账本的情况，而每家每户可以通过有没奔小康什么的来反映村长写的账本的情况（视图表现数据模型）。MVC的优点大部分用过程语言比如ASP、PHP（PHP5也与时俱进了，也具有了面向对象性）开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。MVC要求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。MVC的不足MVC的不足体现在以下几个方面：（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。（4）目前，一般高级的界面工具或构造器不支持MVC架构。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。package{ importflash.events.Event; importflash.display.Sprite; importmvc.*; [SWF(width='550',height='400',backgroundColor='#FFFFFF',frameRate='60')] publicclassBasicMVCextendsSprite { privatevar_model:Model; privatevar_view:View; privatevar_controller:Controller; publicfunctionBasicMVC() { _model=newModel(); _controller=newController(_model); _view=newView(_model,_controller); addChild(_view); } }}packagemvc{ importflash.events.Event; importflash.events.EventDispatcher; importflash.events.KeyboardEvent; importflash.ui.Keyboard; publicclassController { privatevar_model:Object; publicfunctionController(model:Object):void { _model=model; } publicfunctionprocessKeyPress(event:KeyboardEvent):void { switch(event.keyCode) { caseKeyboard.LEFT: _model.direction="Left"; break; caseKeyboard.RIGHT: _model.direction="Right"; break; caseKeyboard.UP: _model.direction="Up"; break; caseKeyboard.DOWN: _model.direction="Down"; break; } } }}packagemvc{ importflash.events.Event; importflash.events.EventDispatcher; publicclassModelextendsEventDispatcher { privatevar_direction:String; publicfunctionModel() { _direction="None"; } publicfunctiongetdirection():String{return_direction;}publicfunctionsetdirection(value:String):void{_direction=value;dispatchEvent(newEvent(Event.CHANGE));} }}packagemvc{ importflash.display.Sprite; importflash.events.Event; importflash.events.KeyboardEvent; importflash.ui.Keyboard; importcom.friendsofed.utils.StatusBox; publicclassViewextendsSprite { privatevar_model:Object; privatevar_controller:Object; privatevar_status:StatusBox; publicfunctionView(model:Object,controller:Object):void { _model=model; _model.addEventListener(Event.CHANGE,changeHandler); _controller=controller; _status=newStatusBox(); _status.fontSize=40; _status.x=200; _status.y=175; _status.text="Text"; addChild(_status); addEventListener(Event.ADDED_TO_STAGE,addedToStageHandler); } publicfunctionaddedToStageHandler(event:Event):void { stage.addEventListener(KeyboardEvent.KEY_DOWN,keyDownHandler); } publicfunctionkeyDownHandler(event:KeyboardEvent):void { _cessKeyPress(event); } publicfunctionchangeHandler(event:Event):void { _status.text=_model.direction; } }}简单工厂模式从设计模式的类型上来说，简单工厂模式是属于创建型模式，又叫做静态工厂方法（StaticFactoryMethod）模式，但不属于23种GOF设计模式之一。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。实现方式（附图）简单工厂模式的UML类图(见图)简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。该模式中包含的角色及其职责工厂（Creator）角色简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。抽象产品（Product）角色简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。具体产品（ConcreteProduct）角色是简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。优点工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。缺点由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；这些缺点在工厂方法模式中得到了一定的克服。使用场景工厂类负责创建的对象比较少；客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心；由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。package{/***content:减法类<br>*/publicclassOperationSubextendsOperation{publicfunctionOperationSub(){super();}overridepublicfunctionGetResult():Number{varresult:Numberresult=this.NumberA-this.NumberBreturnresult}}}package{/***content:乘法类<br>*/publicclassOperationMulextendsOperation{publicfunctionOperationMul(){super();}overridepublicfunctionGetResult():Number{varresult:Numberresult=this.NumberA*this.NumberBreturnresult}}}package{/***content:除法类<br>*/publicclassOperationDivextendsOperation{publicfunctionOperationDiv(){super();}overridepublicfunctionGetResult():Number{varresult:Numberif(this.NumberB==0){thrownewError("除数不能为0")}result=this.NumberA/this.NumberBreturnresult;}}}package{/***content:加法类<br>*/publicclassOperationAddextendsOperation{publicfunctionOperationAdd(){super();}overridepublicfunctionGetResult():Number{varresult:Numberresult=this.NumberA+this.NumberBreturnresult}}}package{/***content:所有逻辑计算类的父类<br>*/publicclassOperation{privatevar_numberA:Numberprivatevar_numberB:NumberpublicfunctionOperation(){}publicfunctiongetNumberA():Number{return_numberA}publicfunctionsetNumberA(value:Number):void{_numberA=value}publicfunctiongetNumberB():Number{return_numberB}publicfunctionsetNumberB(value:Number):void{_numberB=value}publicfunctionGetResult():Number{varresult:Number=0returnresult;}}}package{/***content:工厂类<br>*/publicclassOperationFactory{publicfunctionOperationFactory(){