Question

I have created a class that I’ve been using as the storage for all listings in my applications. The class allows me to “sign” an object to a listing (which can be created on the fly via the sign() method like so):

manager.sign(myObject, "someList");

This stores the index of the element (using it’s unique id) in the newly created or previously created listing “someList” as well as the object in a 2D array. So for example, I might end up with this:

trace(_indexes["someList"][objectId]); // 0 - the object is the first in this list
trace(_instances["someList"]); // [object MyObject]

The class has another two methods:

1. find(signature:String):Array
   This method returns an array via slice() containing all of the elements signed with the given signature.

2. findFirst(signature:String):Object
   This method just returns the first object in a given listing

So to retrieve myObject I can either go:

trace(find("someList")[0]); or trace(findFirst("someList"));

Finally, there is an unsign() function which will remove an object from a given listing. This function basically:

1. Stores the result of pop() in the specified listing against a variable.
2. Uses the stored index to quickly replace the specified object with the pop()‘d item.
3. Deletes the stored index for the specified object and updates the index for the pop()‘d item.

Through all this, using unsign() will remove an object extremely quickly from a listing of any size.

Now this is all well and good, but I’ve had some thoughts which are making me consider how good this really is? I mean being able to easily list, remove and access lists of anything I want throughout the application like this is awesome – but is there a catch?

A couple of starting thoughts I have had are:

1. So far I haven’t implemented support for listings that are private and only accessible via a given class.
2. Memory – this doesn’t seem very memory efficient. Then again, neither is creating arrays for everything I want to store individually either. Just seems.. Larger.. Somehow.

Any insights?

I’ve uploaded the class here in case the above doesn’t make much sense: https://projectavian.com/AviManager.as

Answer 1

Your solution seems pretty solid. If you’re looking to modify it to be a bit more extensible and handle rights management, you might consider moving all those individually indexed properties to a value object for your AV elements. You could perform operations like “sign” and “unsign” internally in the VOs, or check for access rights. Your management class could monitor the collection of these VOs, pass them around, perform the method calls, and the objects would hold the state in a bit more readable format.

Really, though, this is entering into a coding style discussion. Your method works and it’s not particularly inefficient. Just make sure the code is readable, encapsulated, and extensible and you’re good.