ActionScript 3.0设计模式探索

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

"AdvancED.ActionScript.3.0.Design.Patterns" 本书“AdvancED.ActionScript.3.0.Design.Patterns”深入探讨了ActionScript 3.0中的设计模式，旨在帮助开发者理解和应用这些模式来解决编程问题。设计模式是一种抽象概念，它通过模糊的表述来处理复杂的问题，虽然这使得它们难以定义，但并不意味着难以理解。书中强调了面向对象编程（OOP）与设计模式之间的紧密关系。在进入设计模式主题之前，书的前几章会详细讨论OOP的基础原则。这部分内容可能会对一些读者来说是复习，但对于所有读者来说，这些都是后续章节的基础。每一章都为下一章做了铺垫，直到第5章的第一个复习测验，读者会不断巩固自己到目前为止学到的知识，同时构建对设计模式理解的基础。从第6章到第8章，作者深入地涵盖了多种设计模式。每一种模式的讨论都是以实际示例为基础，让读者能够直观地看到如何在ActionScript 3.0中实现和应用这些模式。设计模式如单例模式、工厂模式、观察者模式等，都是软件开发中的重要工具，它们能提高代码的可读性、可维护性和可复用性。本书不仅适合有一定ActionScript基础的开发者，也适合希望提升其编程设计能力的读者。通过学习这些模式，开发者可以更有效地组织代码，减少重复工作，同时提高软件架构的灵活性和扩展性。无论是在创建复杂的Flash应用程序，还是在构建互动性的网页内容时，掌握ActionScript 3.0的设计模式都将极大地提升开发效率和代码质量。 “AdvancED.ActionScript.3.0.Design.Patterns”是一本面向高级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页未读，继续阅读

DoomLord

粉丝: 114
资源: 1318

ActionScript 3.0设计模式探索

Flash.ActionScript.3.0动画教程：全面学习资源集合

Flash.ActionScript.3.0高级教程：动画制作精华

Flash.ActionScript.3.0高级教程：全面学习资源

Adobe.Press.Advanced.ActionScript.3.with.Design.Patterns.Nov.2006

Advanced.ActionScript.3.with.Design.Patterns

advanced.actionscript.3.with.design.patterns

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

高级ActionScript 3.0 设计模式

Kindle Computer Science other.rar

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

最新资源