Thanks for your patience in my getting back to you. Your query about a better way to drag objects is perfectly reasonable, but probably outside of the realm of design patterns in this sense—it concerns comparative algorithms with different syntaxes. Design patterns in computing are really about larger issues, and the level of abstraction is one that asks questions about re-usability and maintenance of programs with multiple classes.

However, your question about the Factory Method is pertinent to the issues we’re pondering on this blog. The Factory Method is one of the essential design patterns (see Chapter 2 in our book) and in several places on this blog. It is important because it helps to loosen up a program. By separating the creation of an object (in a ‘factory’ class identified as a creation participant) from its use by a Client class, you are able to loosen the relationship between creation and use. In this way, it’s a lot easier to change and update a program because you don’t have to worry about making changes that will slither through your program and disrupt one part with the added materials.

As for a list of popular design patterns with examples in AS3–that’s what our book and this blog is all about. It’s full of examples. Enjoy!

Kindest regards,
Bill

The funny thing is, I have an intense love for logic, and often I get gut feelings about what is a good idea or bad idea, even though I can give no clear reason, (such as the “prototype” property, just seems like a really bad idea, still not sure why) and often I find that I have been following certain design patterns without knowing.

I still don’t understand exactly why you used the Factory Method. I have an idea, but I’m not sure if it is an existing design pattern or just some unstructured code, or the advantages and disadvantages to using my idea compared to the Factory Method.

I was considering taking a different approach, creating your own dragging system. Since all DisplayObjects, weather Sprites or not, can listen for mouse events, it would be a lot easier to pick up on that.

Clients would create new “DragListener” instances. A DragListener listens for MOUSE_DOWN and MOUSE_UP parameters from one passed in object, and if the bounds are within a passed set area (likely a reference to a Rectangle, or can even be references to a Shape object or bitmap, with individual pixels tested using hitTest, or a custom hitArea object), the DragListener instance will dispatch “DragEvents”.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

class DragListener extends EventDispatcher
{
   public function DragListener(mouseEventDispatcher:IEventDispatcher, hitArea:HitArea)
   {
      mouseEventDispatcher.addEventListener(MouseEvent.MOUSE_DOWN, startDragDetection);
   }
 
   public property mouseEventDispatcher:IEventDispatcher;
   public property hitArea:HitArea;
 
   private var startX:Number;
   private var startY:Number;
 
   function startDragDetection(mouseEv:MouseEvent)
   {
      if (hitArea.testPoint(mouseEv.location))
      {
         mouseEventDispatcher.addEventListener(MouseEvent.MOUSE_MOVE, moveDetection);
         mouseEventDispatcher.addEventListener(MouseEvent.MOUSE_UP, stopDragDetection);
         mouseEventDispatcher.removeEventListener(MouseEvent.MOUSE_DOW, startDragDetection);
 
         startX = mouseEv.localX;
         startY = mouseEv.localY;
 
         this.dispatchEvent(new DragEvent(DragEvent.START, startX, startY, 0, 0));
      }
   }
 
   function moveDetection(mouseEv:MouseEvent)
   {
      this.dispatchEvent(new DragEvent(DragEvent.MOVE, startX, startY, mouseEv.localX, mouseEv.localY));
   }
 
   function stopDragDetection(mouseEv:MouseEvent)
   {
      mouseEventDispatcher.removeEventListener(MouseEvent.MOUSE_MOVE,
moveDetection);
      mouseEventDispatcher.removeEventListener(MouseEvent.MOUSE_UP, stopDragDetection);
      mouseEventDispatcher.addEventListener(MouseEvent.MOUSE_DOWN, startDragDetection);
 
      this.dispatchEvent(new DragEvent(DragEvent.STOP, startX, startY, mouseEv.localX, mouseEv.localY));
   }
 
}

Here is pseudo code for how the DragEvent could look, ignoring non-essential or irrelevant properties and code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

 
class DragEvent extends Event
{
   public static const START;
   public static const MOVE;
   public static const STOP;
 
   public function DragEvent(eventString:String, startX, startY, currentX,
currentY)
 
   public readonly property currentTarget;
   public readonly property eventString;
 
   public readonly property startX;
   public readonly property startY;
   public readonly property currentX;
   public readonly property currentY;
 
   //The x and y values last dispatched - for simplicity
   public readonly property lastX;
   public readonly property lastY;
 
   //Yes, a long name, I know. Yet, descriptive
   public readonly property offsetSinceLastX;
   public readonly prpperty offsetSinceLastY;
 
   public readonly property offsetX
      {  return currentX - startX; }
   public readonly property offsetY;
      {  return currentY - startY; }
 
} // END DragEvent -----------------------------------------
-----

Finally, here is some sample code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

 
 
   //None of the below are really display objects or can listen for mouse
events
   var line1:Line;
   var circle1:Circle;
   var rectangle1:Rectangle; //Real AS3 class, but not a display object
   var movie1:Video; //This is a display object, but has no "startDrag" function
   var sprite1:Sprite //This has a startDrag function, but we won't be using
it
 
   //For the line, we have told it to only move once the mouse
   //has come to a complete stop in the dragging
   var lineDragger:DragListener = new DragListener(stage, line.hitArea);
   lineDragger.addEventListener(DragEvent.STOP, onStop);
   function onStop(dragEv:DragEvent)
   {
      line1.x += dragEv.offsetX;
      line1.y += dragEv.offsetY;
 
      //Redraw the line now
      this.graphics.clear();
      this.graphics.drawLine(line1);
   }
 
   //Listen on the entire stage, and drag the circle and
   //rectangle at the same time and just as much
   //updating each frame
   var shapeDragger = new DragListener(stage, stage);
   var rectStartX, rectStartY;
   var circStartX, circStartY;
 
   shapeDragger.addEventListener(DragEvent.START, onStart);
   function onStart(dragEv:DragEvent)
   { //Set the start X and Y values for the circle and rectangle  }
   shapeDragger.addEventListener(DragEvent.MOVE, moveShapes);
   function moveShapes(dragEv:DragEvent)
   {
      circle.x = circStartX + dragEv.offsetX;
      //etc...
   }
 
   //You get the point...
 
}

These events are more of suggestions for the target object to move to a certain area, and don’t really need to be followed. Objects can choose weather or not to do anything in the listener functions.

This will allow even objects that are not DisplayObjects (such as lines drawn with the Graphics class) to be dragged as well. In addition, only one display object can be dragged with startDrag at a time, while many objects can be dragged with either several instances, or one instance dragging several objects.

I’m not sure if my thinking is way off the road from Design Patterns…

There would be a bit of a difference for different coordinate spaces, and not all objects may have a “mouseX” and “mouseY” property, but a third parameter or a separate property could easily contain a simple system which points to which property names to look for these coordinates.

Also, do you have any compiled list of popular design patters with perhaps some AS3 example? It would be really handy if you extended the “variation table” with a feature that allows you to double click on an item for examples and more information.

Looking forward to reading the rest of your posts,
Andreas

The thing about design patterns that is most important for me is that they help me rid myself of some pretty bad practices. Also, I’ve learned to be patient with both design patterns and myself. When I’ve learned other aspects of coding, the syntax, key statements and structure have come very fast. However, design patterns rarely come fast, and they’re difficult. Okay, so they’ll take a bit longer, but there’s no hurry. Just poke here and poke there, and pretty soon you’ve got a set of better coding practices that follow the principles that have developed over the years in computer science and related fields. As the practices improve, you’ll start seeing your code take a different direction.

Your point about developing small e-learning interactions is probably true with a lot of people using Flash and Flex—it has been with me as well. Actually, the small projects make it a bit easier to try out some different design patterns. Tackling a big project with a complex system of coding may actually take longer, and the only thing you get sooner is the realization that design patterns are handy little critters.

Kindest regards,
Bill

I tend to develop small e-learning interactions and sometimes struggle to see how DP’s are relevant to my work but this post gave me something to ‘hook’ into and ‘take to work’.

On the odd occasion I do build something more complex, I seem to have adopted the learning philosophy of make as many mistakes as one coder possibly can, then slowly learn from them.

Switching from AS2 to AS3 has helped to curtail some of my more, er, ‘unique’ coding practices but my gut tells me that design patterns will help me work smarter / have more time for beer.

So, thanks again and I look forward to future posts.

Cheers,
Patrick