ActionsScript 3.0 Design Pattern Relations 模式

2010-02-26 12:15 宝宝合凤凰阅读(772) 评论(0) 收藏举报

Archive for the 'Class Relations' Category

ActionsScript 3.0 Design Pattern Relations Part IV: Creation

Published on February 18, 2010 in Class Relations and Creates. 0 Comments

Creates Relationship

One of the least discussed relations in Design Patterns is where one participant creates an instance of another. Basically, the pattern calls for one class to instantiate another class. This relationship is indicated by a broken line with an arrowhead pointing to the class that has been instantiated. (The Participant Relations diagram above shows Class C instantiating (creates) Class F with the red broken line and arrow.) The creates relationship is found in only five design patterns:

This post examines how design patterns incorporating a creates relationship uses that relationship to make a loosely structured design to complete one or more kinds of tasks.
Continue reading ‘ActionsScript 3.0 Design Pattern Relations Part IV: Creation’

ActionsScript 3.0 Design Pattern Relations Part III: Inheritance

Published on February 9, 2010 in Inheritance. 0 Comments

Inheritance Relations

An open triangle on a line from a child class to the parent class indicates the inheritance symbol in Design Pattern class diagrams. In the Participant Relations diagram above, you can see symbols for both single and multiple inheritance in red. Inheritance in design patterns is so common, pointing out which designs do not use inheritance is easier than listing all of the ones that do. Those pattens that have no inheritance in their design include:

So when thinking about inheritance, you can begin by thinking design patterns because most include some kind of inheritance in the relations between pattern participants.

But I thought they said…

You’re probably thinking that a key principle for design patterns is to favor object composition over class inheritance, and here we find that the Gang of Four is using inheritance in all but three of their design patterns. What’s up with that?

Continue reading ‘ActionsScript 3.0 Design Pattern Relations Part III: Inheritance’

ActionsScript 3.0 Design Pattern Relations Part II: Aggregation

Published on January 26, 2010 in Aggregation, Class Relations and Delegation. 4 Comments

Aggregate Relations

I’m tempted to say that aggregation is a stronger form of acquaintance, and that wouldn’t be far from wrong. In fact, in certain contexts it may be perfectly correct. Gamma, et al point out that the differences between the two is a matter of intent rather than explicit language mechanisms. That makes it a little tricky simply to show some code and pronounce, “See that’s what an aggregate looks like.” So bear with me as we look at aggregate relations.

Conjoined Participants

As can be seen in the red arrow symbols in the Participant Relations diagram at the top of this post, an aggregate relation is indicated by an arrow with a diamond at its base. The GoF illustrate the relationship as shown in Figure 1:

Figure 1: Aggregator and Aggregatee

The Aggregator creates an aggregate instance of the Aggregatee. As noted, GoF point out that no single code set can demonstrate what an aggregate relationship looks like, but I think that we can get a start by looking at a fairly simple relationship in the State design I created so that we could discuss both aggregate relations and delegation. (The Strategy design also provides a good example of aggregation with delegation.)
Continue reading ‘ActionsScript 3.0 Design Pattern Relations Part II: Aggregation’

ActionsScript 3.0 Design Pattern Relations Part I: Acquaintances

Published on January 16, 2010 in Acquaintance, Association, Class Relations and Delegation. 6 Comments

Class Relations

This post is the first in a series where I hope to discuss all of the key relationships between classes in Design Patterns. To help identify posts in this series I’ve created a general diagram with all of the different kinds of relationships between classes. I did not include the boxes for pseudo-code or divide the classes into areas for operations and properties. The purpose is to focus on the relationships in this series. You may have noticed that the chart is titled, Participant Relations, and by Participant, I’m referring to any class or interface in a design pattern using the Gang of Four’s terminology. In order to help you quickly see the current relationship topic, the Participant Relations diagram shows the currently discussed relations in red.

UML Controversy: Tempest in a Teapot

In this and subsequent posts, I’m sticking with the notations used by GoF. If you’re into UMLs, you’ll know that GoF actually use a few non-standard notations, but I think that by using the ones GoF use our discussion will be less confusing. If you’re interested in a more standardized UML notation take a look at Judith Bishop’s book, C# 3.0 Design Patterns (O’Reilly) on pp.4-5.

GoF discuss abstract classes and interfaces as interfaces. So, in an example where an abstract class is used, you’ll see an italicized class name. If an interface is used, you’ll see the same thing. In some respects this can be quite helpful in that when you see any italicized text in a class diagram you’ll think interface and know that you can develop your own design pattern using either an abstract class or interface.

The inheritance symbol, that we’ll be covering in detail in a later post, is used to denote both inheritance (extends) and implementation (implements). This is consistent with GoF’s interchangable use of abstract classes and interfaces and their notations. So bear with me on these idiosyncrasies and help focus on the relationships between participants.
Continue reading ‘ActionsScript 3.0 Design Pattern Relations Part I: Acquaintances’

No New is Good New: Using Inheritance, Composition, Delegation and anything else other than New in ActionScript 3.0 Design Patterns

Published on September 19, 2008 in Class Relations and Principles. 4 Comments

bucketrule

Before examining why instantiating instances using new is not a good thing, let me explain where I got the idea. It came from the GoF (indirectly) and the Freemans’ Head First Design Patterns (directly). This is not to say that both acquaintance and aggregation type relationships cannot hold a reference to another class by instantiating an instance of the other class. (The Proxy example on this blog does that.) Likewise, it may be impossible to do serious development without using at least some new statements and so the title indeed contains a bit of hyperbole.

The key idea behind design patterns is that you want your programs to be as flexible as possible. The dictum, program to an interface, not an implementation is an invitation to more flexible designs. When you create an instance using new in effect you lock into using the specific implementation. The more new statements in a program, the more tied up it is in whatever implementation you’ve elected to instantiate.

At the same time, I wanted to go over the different class relationships to connect the conceptual with the actual. When I look at a class diagram and see different relationships between classes, often I feel queasy about the relationships independent of a specific example. This is especially true with non-ActionScript 3.0 examples where the application invokes some built-in feature of the alien language. Suddenly, the example is sucked into a black hole remaining a mystery for ActionScript developers. We’ll avoid that here.

Inheritance Is-A First Step

We are advised by the Gang of Four to favor composition over inheritance, but inheritance is a fundamental part of most design patterns, so it’s a good place to start. It’s also the easiest place to show where you can invoke a method without using new, We’ll begin with the symbol in the class diagram in Figure 1.