欣赏ActionScript 3 的元件架构

简介:

欣赏ActionScript 3 的元件架构。
  ActionScript 3 中所有可以被看到的视觉元件都统一于DisplayObject,即其子类的实例。DisplayObject是一个抽象类,不能生成实例。从系统架构设计上来说,这样的超类设计是常识。DisplayObject,我在AS3.0教程(5):强大的事件机制(1)中讲过,继承于EventDispatcher类,也就意味着所有的DisplayObject子类都可以发送事件了。

  啊哈,DisplayObject下面一层的抽象就精彩了,架构设计师的原意是将所有视觉元件分为两大类:可以接受人机交互事件的,和不可以接受人机交互事件的。所以就有了InteractiveObject类和非InteractiveObject类之分。由于非InteractiveObject的几个类之间差别太大,也抽象不出什么共同点,所以,干脆就分成了InteractiveObject的六个同级兄弟 AVM1Movie, Bitmap, MorphShape, Shape, StaticText, Video。但黑羽认为从系统的优雅性出发,不妨就设一个UnInteractiveObject的超类,将这六个孩子放在这个超类的下面。还便于日后的功能扩展。

  在讲最重要的InteractiveObject之前,我们先把这几个不伦不类的兄弟先扫掉。这几个子类中,我们把它分为可以代码创建的,和不可以代码接触的。所谓不可以代码创建的,是指只能通过Flash创作工具来创建的。和以前一样,StaticText还是不可以用代码实现。另外一个是MorphShape,这个东东是指在Flash中创建Shape形变时,由Flash Player自动生成的,同样的,代码无法实现。

  剩下的几个都是可以用代码创建的:Bitmap,位图对象,可以通过BitmapData对象来创建,也可以从外部载入,比如通过loader。Shape,形状,专门用来绘制矢量图的,通过Graphic对象创建的。Video,视频对象,专门用来播放视频的,可以来自文件也可以来自网络流媒体。

  下面要说到的是AVM1Movie,所谓AVM1Movie,意思就是说Actionscript Virtual Machine 1所支持的SWF影片,也就是ActionScript 1和2的影片。由于ActionScript 3 采用的是AVM2,所以和AVM1影片无法跨脚本交流,必须要把它同AVM2 swf影片区分开来,所以有个这个类。关于这个,感兴趣的兄弟看我的这篇文:小谈ActionScript 3.0与AS 2.0,1.0的swf兼容性。这个一般我们不用关心,也不用直接接触,一旦我们加载一个AVM1老影片到AVM2 swf中时,Flash Player 会自动创建一个AVM1Movie的实例包装这个swf。我们打交道的往往是装载AVM1 swf的容器元件。

  到了InteractiveObject下一层了,这一层共有三个类。

  这一层的抽象理念又要赞一下。架构设计师又用了一个容器和非容器的概念来区分视觉元件。所谓容器,就是可以在其中加载其他的DisplayObject子类对象。当然也包括它的叔叔们,即非InteractiveObject的那几个类。所谓非容器,那就是说不能在它的视图里面加入其他的DisplayObject了。“容器”,这个公共性质实在太重要了,在这一层才这样抽象出来实在很高明,很到位。

  那么老套路,先讲讲非容器的两个类,TextField和SimpleButton。 TextField,就基本上是我们熟悉的动态文本框,这里暂不细说。来说说SimpleButton,这个名字虽然和我们在ActionScript 2中碰到的SimpleButton一样,但实际上二者有很大的差别了。实质上,ActionScript 3 中SimpleButton这个类是将Button这个重要常用的UI控件单独提出作为一类,而不是像以前和MovieClip混淆不清。谁都知道,在ActionScript 2和1中,只要改改MovieClip前几个帧的标签,这个MovieClip就变得和Button一样了。关于SimpleButton的使用,可以说非常简洁实用,这个放在后面细说。我在这里所要强调的是Button和MovieClip不是一个性质。虽然ActionScript 3中Sprite和其子类也可以通过buttonMode来做出和Butoon相似的行为,但原理是不同的。

  剩下的就是DisplayObjectContainer类了。DisplayObjectContainer的所有子类对象,都可以在其中添加其他DisplayObject子类对象。但要注意一点,DisplayObjectContainer本身也是一个抽象类,不可以生成实例。这是出于架构设计稳健性扩展性的考虑,和将DisplayObject设计成抽象类的原因一样,不多说了。

  重要的是看看它的几个子类,Sprite, Loader, Stage。 Stage,就是舞台,所有的视觉元件都是在它之中,当之无愧是最终容器,放在这一层也是合情合理。 Loader就有趣了,它把以前MovieClip装载的部分全部抽象分离出来了。所有和外部资源的加载,都是通过Loader来进行的。而Loader也不能直接和网络资源打交道,要通过专门的URLRequest对象来进行,各司其职,非常好。Loader能干什么?装载swf, 和各种图片。注意,视频还是要通过Video类来进行,直接addChild到各种Container中,不一定要放在Loader中。

  下面来了Sprite,这个3.0中我们打交道最多的容器了。一句话,它是去掉了时间轴的MovieClip(即MovieClip被阉掉了)。如我开头例子所说,倘若我们只是为了创建一个容器,那么Sprite是首选。甚至可以说,我们这些写代码的开发人员,90%以上的情况都只需要和Sprite打交道。含有时间轴的MovieClip一般是Flash工具创建出来的,往往只需要加载就可以了。准确的说,Sprite比ActionScript 2中的MovieClip不止少一个TimeLine,如装载。Sprite中也含有Graphic对象,这意味着,它也可以直接在其中代码绘图。但我们始终要记住,Sprite不同于Shape,区别就在于Sprite是容器,而Shape不是。从代码角度说,就是,Sprite可以addChild(),但Shape不可以。

  都说到这儿了,我们亲爱的MovieClip还不见踪影,到底在哪儿了呢?其实就在Sprite的下一层。Sprite下一层中,共有四个子类,MovieClip是其中一个。大家可以想到,现在的MovieClip重要性大不如前了,主要就是代表用Flash创建的含有时间轴的影片。常用的gotoAndStop, currentFrame等等这些属性现在才能碰到了。

  其余三个子类,也是来头不小,最牛的就是其中的FlexSprite。虽然它的改动只是变了一下toString()函数,但它却是所有Flex组件的共同基石。著名的UIComponent的老爸现在就是它了。UIComponent何许人也?天下组件,皆由它出。黑羽大胆预测,我们在Flash 9中所要用到的控件,也就是现在的Flex里面的组件,即mx.controls里面的所有组件。此类不可小看。

  另两个子类Preloader和DownloadProgressBar,已经不属于flash.display包了,而是属于mx.preloaders包,主要管理的是下载进度和共享库的下载等功能,不予细说了。

  到此,ActionScript 3 主要的视觉元件架构已经理出了一个清晰的脉络,设计的原因,理由,思路都做了一一剖析,希望大家喜欢。其实InteractiveObject下的另外两根枝条TextField和SimpleButton也有很重要的地位,在后续教程中会一一细说。

  下面到了老鸟时间了,和老鸟们分享一下我对ActionScript 3 视觉架构的分析心得。可以看出的是,抽象的界限非常明确,应用的模式也比较统一。应用的模式就是OOP编程中最常用的模式之一:Composite模式。比如Shape下的Graphic对象,Sprite下面的SoundTransform对象,Loader下的LoaderInfo对象,等等等等。我本来迷惑,为何不用装饰器模式,让这些元件的行为和ActionScript 2更加相似一些,过渡的痛苦少一些,但转念一想明白了架构设计师的苦心。就是要用这样清清楚楚,明明白白的Composite来加强所有开发者OOD时分工协作,更加快的熟悉和运用新的强大的架构。与这个优点相比,这么一点过渡的痛苦又算得了什么呢?

  关于ActionScript 3视觉编程后续部分和具体的编程例子,会陆续放出。

  P.S:本教程受Creative Commons License.协议保护,未经作者同意,不得用于商业用途。
本文转自jiahuafu博客园博客,原文链接http://www.cnblogs.com/jiahuafu/archive/2009/06/30/1514157.html如需转载请自行联系原作者

jiahuafu

相关文章
|
10天前
|
传感器 监控 安全
智慧工地云平台的技术架构解析:微服务+Spring Cloud如何支撑海量数据?
慧工地解决方案依托AI、物联网和BIM技术,实现对施工现场的全方位、立体化管理。通过规范施工、减少安全隐患、节省人力、降低运营成本,提升工地管理的安全性、效率和精益度。该方案适用于大型建筑、基础设施、房地产开发等场景,具备微服务架构、大数据与AI分析、物联网设备联网、多端协同等创新点,推动建筑行业向数字化、智能化转型。未来将融合5G、区块链等技术,助力智慧城市建设。
|
2月前
|
Cloud Native API 持续交付
云原生架构下的微服务治理策略与实践####
本文旨在探讨云原生环境下微服务架构的治理策略,通过分析当前面临的挑战,提出一系列实用的解决方案。我们将深入讨论如何利用容器化、服务网格(Service Mesh)等先进技术手段,提升微服务系统的可管理性、可扩展性和容错能力。此外,还将分享一些来自一线项目的经验教训,帮助读者更好地理解和应用这些理论到实际工作中去。 ####
72 0
|
2月前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
303 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
2月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
2月前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
109 8
|
3月前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
65 1
|
3月前
|
负载均衡 Java 持续交付
深入解析微服务架构中的服务发现与负载均衡
深入解析微服务架构中的服务发现与负载均衡
168 7
|
3月前
|
消息中间件 运维 Cloud Native
云原生架构下的微服务优化策略####
本文深入探讨了云原生环境下微服务架构的优化路径,针对服务拆分、通信效率、资源管理及自动化运维等核心环节提出了具体的优化策略。通过案例分析与最佳实践分享,旨在为开发者提供一套系统性的解决方案,以应对日益复杂的业务需求和快速变化的技术挑战,助力企业在云端实现更高效、更稳定的服务部署与运营。 ####
|
3月前
|
弹性计算 运维 开发者
后端架构优化:微服务与容器化的协同进化
在现代软件开发中,后端架构的优化是提高系统性能和可维护性的关键。本文探讨了微服务架构与容器化技术如何相辅相成,共同推动后端系统的高效运行。通过分析两者的优势和挑战,我们提出了一系列最佳实践策略,旨在帮助开发者构建更加灵活、可扩展的后端服务。
|
3月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
83 3

热门文章

最新文章