Hey, pseudo-code is fine. It gets the idea across, and I really am planning on getting back to the dual dispatch concept written in AS 3.0 as soon as I can get the Mediator wrestled to the ground. I’m trying to work through how one abstract class can hold a reference to another abstract class/interface. If I can quickly get Dan’s code running in AS 3.0, I’ll do it. (Unless someone else would like a shot….)

Take care,
Bill

The code I posted is just pseudo-code (hopefully looks like AS) which was just a translation of Dan Ingall’s Smalltalk code snippets.

Let me just make another point about OOP and conditionals. An OOP program or system is a fundamentally little more than a bunch of conditionals. An object in a true OOP language, I’d argue, has 3 things: identity, instance data, and behavior. The behavior of an object is analogous to a big switch statement mapping method selectors (messsage names or method signatures) to actions. Given this, often a switch statement can be refactored into a message send and vice versa. (There are many factors that influence when this refactoring is a good idea and I’ll leave that to further discussion.)

…Mike

Are you going to OOPSLA in Nashville later this year? I hope to be able to have a presentation there in the same session I have for the last two years (Killer Apps). It would be great to see someone else using ActionScript there.

Did you do it with Flex or Flash?

Thanks,
Bill

public interface IDisplayPort {
    function displayRect (r:Rectangle): void;
    function displayString (t:Text): void;
    function displayOval (r:Rectangle): void;
    function displayBitmap (b:Bitmap): void;
}
public interface IDisplayObject {
    function displayOn (port:IDisplayPort): void;
}
public class Rectangle implements IDisplayObject {   
     function displayOn (port:IDisplayPort) {
        port.displayRectangle (this);
    }
}
public class Bitmap implements IDisplayObject {
    function displayOn (port:IDisplayPort) {
        port.displayBitmap (this);
    }
}
public class Oval implements IDisplayObject {
    function displayOn (port:IDisplayPort) {
        port.displayOval (this.boundingBox ());
    }
public class Text implements IDisplayObject {
    function displayOn (port:IDisplayPort) {
        port.displayText (this):
    }
}

Likely implementors of IDisplayPort are screen objects, printers, bitmaps, graphic files, etc.
Now if you’re positive you need exactly 2 kinds of display ports and exactly 2 kinds of display objects, putting all the login in a single method with conditionals is easier. But if there are many kinds of display ports and many kinds of display objects, double dispatching makes it much more manageable. It resolves (without conditionals) one kind of display object paired with one kind of display port to a single method (er, function). This same technique can be extended to triple dispatching (and more).

…Mike

Welcome to the discussion. Now I’ve got to admit that I don’t know jack about double dispatching, but I’m willing to learn. How about a piece of sample code in ActionScript 3.0 or a little app that uses it? Maybe even a little DP that shows what DD can do.

I found a clear description of double-dispatch on page 338 of the GoF’s book, Design Patterns, and right after the Mediator DP that I’m working on now, I’ll have a run at the Visitor pattern that uses double-dispatch. The Visitor patterns allows you to add operations (methods?) to classes without changing them. The executed operation depends on the kind of request and the types of two receivers. It sounds intriguing and as you said, negates the requirement for a conditional.

Naturally, if you’d like to show us how ActionScript 3.0 can be employed in a simple Visitor pattern; we’d be delighted!

Thanks a million,
Bill

Smalltalk didn’t have conditionals (syntactically) - the effect was achieved with the behavior of Booleans and Blocks. I don’t think this is feasible in ActionScript because you can’t add the requisite behavior to all the booleans you’re likely to encounter (I don’t think). But ActionScript is so much more dynamically flexible than languages from which it inherited it’s syntax (C, Java), it supports a style of programming much less reliant on conditional syntax.

Which brings me to my favorite pattern, the most overlooked and fundamental pattern of all time: double dispatching. Double dispatching can be used to significantly reduce conditionals, often leads to “better” factored code (IMHO).

…Mike

Each case is a different class. As each class is called, all of the possible and/or correct conditions are put forth. It’s a lot more work, but it takes out the conditional switch statement.

Bill

switch (overlayItem.dockSide)
{
	case DockSide.TOP:
		//put the item at the top
		break;
	case DockSide.BOTTOM:
		//put the item at the bottom
		break;
	case DockSide.LEFT:
		//put the item at the left
		break;
	case DockSide.RIGHT:
		//put the item at the right
		break;
};

Greetz Erik

I admit that broaching the issue turned out to be heuristic, and so naturally I’m glad I did. To do justice to the author of the idea whom I met at OOPSLA, I probably should have set it up more clearly. However, the State Design Pattern is characterized by the lack of conditional statements. Instead, by selecting a context, all of the outcomes are already determined and so you don’t need conditional statement.

After this exercise, though, I’ve got to admit that I’d be hard-pressed not to use conditional statements in most of the other design patterns. Chandima and I hope to continue pushing the envelope in this area, and everyone who’s got an idea or a comment is always welcomed here. In the meantime, I’m trying to find time to get the next design pattern done!

Take care,
Bill