[Fling] Using composite pattern to handle the AssetManager

Thu May 25 15:32:03 EDT 2006

sorry if it came across blunt, been debugging all day so etiquette went out the window.

What I meant to really say it what benefit would the pattern give us on those two classes?  I beleive simon is a hard core flash programmer and one of the most known people in the flash/actionscript community and he could could and understand this stuff in his sleep.  However a lot of developers are not as skilled and design patterns in some cases tend to confuse than simplyify.

I am a little jaded as I lead teams of developers and design patterns are abused generally, when a new programmer shouts excitedly about how he just learned design patterns I close my door and start drinking heavily...

I believe design patterns are essential to frameworks and fling will undoubltby use lots of them, infact I'm going to compete with chris to see how many I can jam in there (j/k).  But I do agree with the moderation comment that Chris put so elequently below.

so anyway, sorry if I came off as blunt, it wasn't meant that way, was just concerned about overengineering.

:)

Grant

________________________________

From: Fling-bounces at osflash.org on behalf of Chris Allen
Sent: Thu 5/25/2006 3:27 PM
To: Fling at osflash.org
Subject: Re: [Fling] Using composite pattern to handle the AssetManager

LOL!

Classic! I'm supposed to lead a discussion on the Decorator pattern in
a couple of weeks, and I might just have to mention what Grant thinks
about design patterns. Everything in moderation is what I have to say.

Grant, if you burn your GOF book, please video tape the ritual. I
really want to see that.

Okay, so I think the consensus is to keep the API simple and that the
composite pattern will just over complicate things and is not needed
for our three levels of hierarchy. I wouldn't have put it quite like
Grant did, but I do agree in principal. Let's not over-engineer this
design.

Simon, thanks for questioning our design and suggesting alternatives.
Doing so is essential in getting Fling where we want it to be. Oh and
take the way that Grant says things with a grain of salt; you will get
used to his ways soon enough. ;-)

-Chris

On 5/25/06, Grant Davies <grant at bluetube.com> wrote:
>
>
>
>
> I'm alittle concerned about the explosion of design patterns in the flash
> world, and although I think they can elegantly solve a problem they often
> make the solution less easy to understand.  If we were churning 5 - 10
> classes that needed similar functionality and would benefit from the
> composite pattern i'd be all for it, but we are talking about 2 fairly
> simple classes, that are also quite easy to understand.
>
> I'm going to burn my GOF book soon, I've had it over 10 years and sometimes
> I think it does more damage than good :)
>
> any, just my humble opinion :)
>
> and Grden you cheap tart, can you fix the reply (to make it reply to the
> list)  :)
>
>
> Grant
>
>  ________________________________
>  From: Fling-bounces at osflash.org on behalf of John Grden
> Sent: Thu 5/25/2006 2:52 PM
> To: Chris Allen
> Cc: Fling at osflash.org
> Subject: Re: [Fling] Using composite pattern to handle the AssetManager
>
>
> I "get it", and I'm somewhat in favor of exploring it. I guess the thought
> is the same that Chris mentioned:  we're well aware of the 3 levels we're
> dealing with, so making it recursive might be overkill and hurt the
> api/usability.  But if it doesn't hurt it, then hey, why *not* have it
> recursive like that.
>
> THoughts?
>
>
>
>
> On 5/24/06, Chris Allen <mrchrisallen at gmail.com> wrote:
> > Hi Guys,
> >
> > I was just chatting with Simon about the AssetManager and he asked why
> > we weren't using a more flexible structure for this implementation. I
> > asked him what he was thinking and this is basically what he suggested
> > in a nutshell.
> >
> > Why not use the composite pattern for this?
> >
> http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/composite.htm
> >
> > Basically, AssetManager and AssetLoader are doing much of the same
> > things (we have a AssetManager that manages a batch of AssetLoaders,
> > which themselves load multiple assets), they are both managing batches
> > of things. They both have the complete, start, progress etc. events.
> >
> > Now, let's say that an AssetLoader is a Leaf, and it loads only one
> > asset. Then we can have an AssetManager as a Composite, that handles
> > multiple AssetLoaders. Both the AssetManager and the AssetLoader would
> > share one common interface.
> >
> > If the AssetManager uses a common interface, you can build a tree as
> > you need it. You can then actually say something like:
> > myAssetManager.addAssetLoader(new AssetManager(...)) because the
> > AssetManager is an AssetLoader that manages multiple leaf
> > AssetLoaders.
> >
> > This is a recursive structure that would allow us to do multiple
> > levels of assets as we see fit.
> >
> > My main concern with this approach is that it might make the API more
> > confusing to use, and quite simply might be overkill when we are
> > generally only concerned with three levels
> > AssetManager->AssetLoaders->Assets. However, it would be
> nice to have
> > a general interface or an abstract class for these two classes
> > regardless so that there is less duplication going on.
> >
> > What are your thoughts on this composite approach?
> >
> > -Chris
> >
> > _______________________________________________
> > Fling mailing list
> > Fling at osflash.org
> > http://osflash.org/mailman/listinfo/fling_osflash.org
> >
>
>
>
> --
> John Grden - Blitz
>

_______________________________________________
Fling mailing list
Fling at osflash.org
http://osflash.org/mailman/listinfo/fling_osflash.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/fling_osflash.org/attachments/20060525/817556e0/attachment-0001.htm