ActionScript 3.0高级设计模式详解：面向对象与模式的深度探索

需积分: 10 110 浏览量更新于2024-07-30 收藏 10.01MB PDF 举报

"《AdvancED ActionScript 3.0 设计模式》是一本于2011年出版的专业书籍，专为ActionScript 3.0开发者设计。该书以英文编著，注重排版清晰度，特别地，为了读者方便，部分前言内容被放置在索引之后，但可通过Bookmarks和Contents链接轻松访问。全书主题围绕设计模式这一抽象概念展开，尽管这个主题在表述上可能有些模糊，但它并不意味着理解起来就复杂。本书对ActionScript和面向对象编程（OOP）有基本要求，但作者巧妙地将这两者紧密结合。前几章首先深入讲解和详述了OOP的基本原则，确保即使是对这些概念有所了解的读者也能从中复习和巩固。在前五章（包括第一次复习测验）中，读者不仅能回顾和增强已有的知识，也为接下来探讨设计模式打下坚实基础。从第六章开始，本书进入核心部分，全面涵盖了设计模式的各个方面。每一种设计模式都会进行详细的阐述和讨论，帮助读者理解并掌握它们如何应用于实际的编程场景。通过逐步学习，读者不仅会提升编程技能，还能学会如何通过设计模式来优化代码结构，提高代码的可复用性和灵活性。《AdvancED ActionScript 3.0 设计模式》旨在让读者在享受解决问题的乐趣中，理解和掌握设计模式的精髓，从而成为更高效、更有策略的ActionScript开发者。无论是初学者还是经验丰富的开发人员，这本书都能提供实用的指导和深度见解，适合那些希望在高级ActionScript开发中运用设计模式的人员。"

OBJECT-ORIENTED PROGRAMMING

You can further ensure that the attributes of the superclass are read-only to each subclassed behavior by

adding public getter methods as additional interfaces of the superclass. Doing so lets each subclass

retrieve attribute values without being able to reassign a value to the reference. To enforce that each

subclass uses the getter methods versus reading the properties to which they currently have access, you

continue to mark all protected attributes of the superclass as private.

This example illustrates the potential power of an object-oriented language. Remaining object-oriented as

you write code, which makes the code easier to maintain and more flexible. Now that we’ve covered the

principles of OOP, let’s focus on their implementation into an object-oriented language.

Note: It’s always easier to say how to properly engineer a better structure after all is said and done. Don’t

be discouraged if you understood the previous example but can’t yet create OOP code on your own. The

goal is to understand how the building blocks add modularity and flexibility while reducing the possibility of

disaster, by following the four principles of OOP.

ActionScript as an Object-Oriented Language

Working with an object-oriented mentality opens the door to a new manner of programming. ActionScript

lets you flexibly develop rich Internet applications (RIAs) when you program according to the four OOP

principles:

• Encapsulation: ActionScript allows for the compartmentalization of behaviors and data into a

class.

• Polymorphism: Objects within a hierarchy can respond to the operations defined by their

hierarch, when indistinguishably messaged by the client.

• Inheritance: Like every class in the API, a custom class is an extension of the most

generalized class in the language. This most basic class is appropriately called Object. The

Object class makes it possible to add custom classes to a system, as long as those classes

use the proper language structure and syntax.

• Data hiding: A class ensures its own behavioral and data security by using namespaces. In the

ActionScript language, five namespaces provide varying levels of security.

• public: Add the keyword public in lowercase before the declaration of variables or

methods. This namespace modifier provides no security. Behaviors and variables can be

seen and manipulated by all classes and objects.

• Internal: The default namespace. This is the first tier of security in that the class is public,

but only to other classes in the same package.

• private: The opposite of public, allowing no access except by the class that made the

private declaration.

• protected: Similar to private, but visibility among properties and behaviors are available to

classes which subclass the class which defines any protected attribute or behavior.

• final: Ensures that either class or method cannot be extended, and thus protects all

declared behaviors or classes form being modified via inheritance.

CHAPTER 1

• Custom namespace: Declaring a custom namespace for either a behavior or an attribute

treats any such modified elements as being private, although it’s only private to classes

which have not opened the custom namespace (we’ll learn more about this later in the

chapter).

Defining an External Definition

Up to now, you’ve explored the principles of OOP and seen how the four principles of OOP work

harmoniously to improve your code architecture. All that remains is to learn how to physically construct

these objects in the AS 3.0 language.

Part of the burden of defining a custom object is that such an object isn’t natively understood by the

compiler. You must tell the compiler what the object does and also where to find it. Essentially, the

compiler must be made aware of an external definition.

Any spoken language can have multiple definitions for a particular word, which may create confusion

during a conversation. Similarly, computers require a way to tell which definition should be used;

otherwise, unexpected errors may arise.

Because it’s impossible to have two files with exactly the same name and extension in the same system

folder, a definition can be differentiated by its location along with its file name. Therefore, each definition

can be viewed as being unique to the compiler.

The location of a definition, noted by its folder structure, becomes the pointer to the appropriate definition.

This is known as a Unified Resource Identifier (URI); it enables the compiler to differentiate among

definitions of similar names.

The first step in creating an external definition is writing the wrapper that surrounds the body of the

definition. This is demonstrated in Table 1-5.

Table 1-5. The skeletal structure of an external definition

package [folder[, folder... ]]{

[visible] type_of_definition DefinitionsName

{

//BODY OF THE DEFINITION;

}

As you can see, to begin a definition, you identify its location using the package directive. This represents

the folder structure where the definition resides. The arrangement of folders for the project is entirely up to

you, but it’s beneficial to group your objects in a manner that represents the relationships between

definitions. This grouping may be apparent in the physical naming of the folders as well as in their

OBJECT-ORIENTED PROGRAMMING

hierarchy. It not only keeps your classes organized, but also gives other developers a clear idea which

definitions are being used and what other objects may be used with them.

As denoted by line 1 in Table 1-5 the package directive is followed by the full path to where the definition

resides, denoted with dot notation. If the class doesn’t reside in a folder structure, then the folder

arguments following the package directive may be left blank.

An example you’re sure to have seen is the import code for the MovieClip class (see Figure 1-3).

import flash.display.MovieClip;

Figure 1-3. The MovieClip import reflects the MovieClip package.

As you can see, MovieClip is a class in a series of nested folders that reveals the nature of the class—you

don’t even need to see the code that MovieClip contains. The import refers to where the location of the

definition used.

If you open the MovieClip.as file, the first line looks like: package flash.display{

Now that you’ve specified the location of your definition, ActionScript expects the type of definition and the

name of the definition. The name must also be that of the saved .as file. Although the package and

filename specify a particular definition, the actual definition, which varies depending on the type of

definition being created, is placed in the body as shown on line 5 of Table 1-5.

ActionScript uses three types of definitions: class, namespace, and interface. The next section, describes

the parts of each definition.

Parts of a Class

Even the most introductory ActionScript books cover the creation of custom classes (see Table 1-5).

Often, this is to demonstrate the use of the language. It would be beyond the scope of those books to

ensure that you have the proper object-oriented mindset as you construct your classes. With this in mind,

don’t be too anxious to skip ahead if you feel you may already be familiar with constructing classes.

Figure 1-4. The expected syntax and structure to properly define a custom class

CHAPTER 1

On line 4 in Figure 1-4, you used the keyword class to signify that the following definition relates to a

class. The class directive can include four additional modifiers, not including its visibility. By default, you

don’t see any of the keywords other than class in your editor, because everything in brackets in Figure 1-

4 is optional; these elements let you make custom modifications to the class.

The first optional modifier is the keyword dynamic. Specifying that your class is dynamic lets you add

properties to your class definition at runtime. Without this modifier, the class is locked: you can’t add new

properties or behaviors later. Dynamic can only be used to modify the definition of the class, not the

properties or methods. Subclasses of a dynamic class can’t inherit dynamic behavior, because it’s specific

to the current definition.

The next modifier specifies the visibility of the class’s definition and defaults to internal, but can be

specified as public to allow any classes outside the declared package view its definition. Although there

are five namespaces that modify visibility, only internal and public can be used to modify the visibility of

a definition.

The last optional attribute, final, specifies that the class can’t be subclassed. Because inheritance is a

significant part of OOP, the use of this final keyword may be confusing, but it enforces data hiding.

Declaring a definition as final prohibits any classes from subclassing the definition. This ensures that the

class can’t be modified, short of physically changing the code in the original file.

Following the class directive, you add a name to identify the definition. To distinguish this from methods

and variables that use camelCase, class names use a capital letter at the start of each word. Class names

should be specific to the behavior they define. An appropriately named class can allude to the behaviors

that a developer expects to find within the definition.

The remaining keywords (extends and implements), again optional, let you add your class to an existing

hierarchy . By default, all classes extend the top-level Object unless specified otherwise. This is why it’s

said that to initialize a class is to instantiate an object. At the core of every class is an Object.

Through the principle of inheritance, your class gains all public and protected, properties and behaviors

of each class in the hierarchy of the chosen superclass.

Suppose we were devising a class named Foo, and Foo requires the abilities possessed by MovieClip.

Choosing to subclass MovieClip looks like the following:

package

{

public class Foo extends MovieClip

{

public function Foo()

{

// constructor code

}

Because ActionScript doesn’t support inheriting from multiple classes, the keyword implements allows you

to add into your class the interface utilized by a specific type. By implementing an interface, in addition

to adding existing public methods to your definition, you are also adding the interfaces type to the

hierarchical chain of your definition as well.

OBJECT-ORIENTED PROGRAMMING

Currently, our Foo class that extends MovieClip can be typed as Object, EventDispatcher,

InteractiveObject, DisplayObjectContainer, Sprite, and finally MovieClip. This is because MovieClip is

the subclass of another subclass, of another subclass, all the way up to the most generic class of all,

Object:

MovieClip

‰ Sprite ‰ DisplayObjectContainer ‰ InteractiveObject ‰ DisplayObject ‰

EventDispatcher

‰ Object

Before you go any further, let’s see what it means to extend from EventDispatcher. As you can see in

Table 1-6, EventDispatcher is a subclass of Object and implements an interface named

IEventDispatcher.

Table 1-6. The composition of EventDispatcher

Inheritance EventDispatcher

‰ Object

Implements IEventDispatcher

IEventDispatcher is referred to as an interface, which, as the word implies, declares the public methods,

and only public methods, with which you can “interface” or interact. If these methods were defined as

anything other than public, then technically you couldn’t use them or interface with them—hence the term.

Therefore, they must be public. An interface isn’t a class, but it requires a name to which a collection of

defined methods can be referred; it too can be used to add another type to your class.

The inclusion of IEventDispatcher demonstrates that the interface is what allows MovieClips and Sprites

to exhibit the public methods listed in Figure 1-5.

Figure 1-5. The IEventDispatcher interface inherited by MovieClip and Sprite

Now that you have your class’s definition, you’re can add the attributes and behaviors to the definition’s

body. You can specify their visibility as private, public, protected, internal, or using custom namespaces,

and you can also declare them as being static.

Static isn’t a visibility modifier, but it establishes whether the attribute or behavior is a member of the

class or the instantiation itself. The difference is that if a behavior or attribute is an instance member, any

assignment is localized to the individual object; but a class member signified via the keyword static is

referenced by every instance (see Listing 1-3).

Listing 1-3. Demonstrates how class members are referenced by every instance

package

{

public class StaticExample

剩余429页未读，继续阅读

fireman_39

粉丝: 1
资源: 2

ActionScript 3.0高级设计模式详解：面向对象与模式的深度探索

AdvancED ActionScript 3.0 动画与高级碰撞检测解析

Flash AdvancED ActionScript 3.0：集成摄像头与麦克风的多媒体应用教程

ActionScript3.0设计模式解析与实践

AdvancED.ActionScript.3.0.Design.Patterns

(FLEX)Advanced ActionScript 3 with Design Patterns - 2006 (Adobe)

高级ActionScript 3.0 设计模式

ActionScript 3.0设计模式探索

ActionScript 3.0进阶：设计模式详解与实践指南

Advanced.ActionScript.3.with.Design.Patterns

advanced.actionscript.3.with.design.patterns

最新资源