[Fling] Using composite pattern to handle the AssetManager

[John Grden]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/fling_osflash.org/attachments/20060525/96d3c59a/attachment.htm