Thanks for your comments. I was able to get this DP off the ground thanks to Jim Kremens initial rendering, and that’s where I first noticed the ..rest parameter. Also, I think that an array was used and I changed it to an associative array (Object) and hung on to the …rest parameter. Others have mentioned the same thing you did about the use of …rest. It’s not so much that it works; it’s that I’m not sure why it lacks that would make it a poor choice. As I keep pounding beyond the FlyWeight, I keep coming back to this same issue, and it is quite helpful to get comments like yours. My problem is that I like going through the agony working to figure out a new DP and since the Mediator is next in line, the little time I have, I spend on getting some ideas for the Mediator. However, after your comments, I’ll revisit the FlyWeight again to see about making improvements.

Take care,
Bill

Another note is about using …rest. You should never use …rest if you are only accepting a single parameter. In the example you only ever look at rest[0]. I realize it is just that, an example, but proper use and simpler use would have been to give it a default value of null, or rather in this case to leave it out altogether.
Now I need to read through your part 2 and 3! Great blog by the way.

I see now. My hunch is that GoF was working with SmallTalk just like we’re working with AS 3.0 and so they used it. Likewise, the Freemans (Head First DP authors) were working with Java and decided (correctly it would seem) that a lot of Java programmers would really like a good clear introduction to DPs.

As far as I’m concerned, I think that AS 3.0, even without gems like abstract and private classes, is as good a candidate for DPs as any language. Right now, most of the examples I’ve found have been written in Java and C#. My hope is that our discussion will bring in more ActionScript programmers and we can all learn from one another like we’re trying to do here.

I could do this night and day….and I’ll try and get Part 2 (of an unknown number of Parts) done soon.

Thank you mucho,
Bill

No, I just know that a lot of the Gang Of Four patterns are presented in SmallTalk, so I’d be curious to know why (or if) this sort of concept is more viable there.

I believe you’re right. I had chatted with aYo some about it, and he too reached the same conclusion. Also, I arrived at the same conclusion you did. First, I think I’m going to try and tackle the extrinsic state as a parameter in an operation. This will also be abstract, but I’m trying to clarify (for myself as much as for anyone else) the role and use of instrinsic and extrinsic states.

I’ve spent so much time with the State design pattern that when I think of states, I too often think of it in that context. What I need to do is to get better clarity on how to work with those states as intrinsic and extrinsic and the whole concept of a stateless object.

You mention that you’re not clear on why the pattern would be more valuable in some other language. I don’t know if it would be. All I know is that it’s been difficult to study examples from SmallTalk and Java because often they use examples that include built-in features in those languages that are not in AS 3.0. However, if I said that they were more valuable in SmallTalk, I certainly didn’t mean it!

Thanks (yet again!),
Bill

I wrote this Flyweight example a few years ago (in AS2, of course) when I ported eight design patterns to AS in order to learn how they worked. After I got it working, I didn’t think about it too much… Over time, I ended up using lots of the other examples, but never the flyweight. Now I see why…
If you need to create a bunch of buttons on the stage, all of them need to be unique instances. You can’t put 3 copies of the same button on the stage and then set 3 different x and y values for that button. Each time you set the x and y values, as you are dealing with only one actual instance, you’ll overwrite the last value you set. They must be discreet instances to have unique property values.

One application I can see of the flyweight is the following: you could use it to configure your button instances. In other words, you might create one ButtonConfigure object that contains values that you know will remain constant for all of your buttons. Then, although you still have to create unique button instances, you can use the same configure object to set properties common to all of them. Properties that need to be unique would be set separately. This is sort of how stylesheets work…

That might be pretty cool… You could configure your button class to accept different ButtonConfigure objects. That would give you a lot of flexibility - the Button class itself could remain really generic - different configure objects would produce very different buttons.

That problem has been solved before, and in most cases without the flyweight. But if you’re looking for an application of this pattern in AS, I think that might be a good one…

I’m not clear on why this pattern might be more valuable in, say, SmallTalk. I’d be interested to learn about that…

Jim Kremens

Thanks for that. I’d really like to see what you develop. My next step is going to be to see how to set up the client to maintain all of the state for all of the virtual button objects. (Actually, I’ll have to use “trace” buttons” until I get the structure right.) I’ll probably stick with Jim’s original Factory structure with the exception that the associative array will be based on an Object class rather than an Array class, and I suspect that the original Client class the Jim made has some important pointers as well.

BTW, I like the ratio of 5:3 in your example. ;O
Bill

An example would be a school with a population of 5000, 3000 chicks and 2000 dudes. Thus we have 2 class, Dudes and Chicks each possessing the property “population” to which the value can be passed. I’ll post my test class/package when I’m done with my muckabouts

I think I have the answer to your question and to a lot to my own. The Factory Method pattern does not inlcude the Client as a participant in its structure. I’ve been (incorrectly) assuming that the Factory participant in the Flyweight pattern holds the state for all (that’s ALL!)of objects (buttons in this case). However, it’s the Client that does. So I’m going to have to wrap my head around the Client to figure out how it holds all of the states, while the buttons will be state-free objects…my brain just left on vacation for Acapuco…

Stay tuned,
Bill

I’m going to talk to Chandima about the Factory Method and the difference between it and the Flyweight. I think I know what Keith meant in reference to a ‘Singleton Factory,’ but let me see if I can find another way of putting it.

Bill