Блог

Я создал класс, который использую в качестве хранилища для всех списков в своих приложениях. Класс позволяет мне «подписывать» объект в список (который может быть создан «на лету» с помощью sign() метода, подобного этому):

 manager.sign(myObject, "someList");
  

При этом сохраняется индекс элемента (с использованием его уникального идентификатора) во вновь созданном или ранее созданном списке «someList», а также объект в 2D-массиве. Так, например, я мог бы в конечном итоге получить это:

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

У класса есть еще два метода:

1. find(signature:String):Array
   Этот метод возвращает массив через slice() , содержащий все элементы, подписанные заданной подписью.

2. findFirst(signature:String):Object
   Этот метод просто возвращает первый объект в заданном списке

Итак, чтобы получить MyObject, я могу либо перейти:

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

Наконец, есть unsign() функция, которая удалит объект из заданного списка. Эта функция в основном:

1. Сохраняет результат pop() в указанном списке в переменной.
2. Использует сохраненный индекс для быстрой замены указанного объекта pop() ‘d элементом.
3. Удаляет сохраненный индекс для указанного объекта и обновляет индекс для pop() ‘d элемента.

Благодаря всему этому использование unsign() чрезвычайно быстро удалит объект из списка любого размера.

Теперь это все хорошо, но у меня появились некоторые мысли, которые заставляют меня задуматься, насколько это хорошо на самом деле? Я имею в виду, что возможность легко составлять списки всего, что мне нужно, удалять их и получать к ним доступ по всему приложению, вот так, потрясающе, но есть ли в этом подвох?

У меня возникла пара начальных мыслей:

1. До сих пор я не реализовал поддержку списков, которые являются частными и доступны только через данный класс.
2. Память — кажется, это не очень эффективно для памяти. С другой стороны, также не создается массивов для всего, что я хочу хранить по отдельности. Просто кажется.. Больше.. Каким-то образом.

Есть идеи?

Я загрузил класс здесь на случай, если вышесказанное не имеет особого смысла: https://projectavian.com/AviManager.as

Ваше решение кажется довольно надежным. Если вы хотите сделать его немного более расширяемым и управлять правами, вы могли бы рассмотреть возможность переноса всех этих индивидуально проиндексированных свойств в объект value для ваших AV-элементов. Вы могли бы выполнить такие операции, как «подписать» и «отменить подпись» внутри VOs, или проверить права доступа. Ваш класс управления мог бы отслеживать коллекцию этих VO, передавать их по кругу, выполнять вызовы методов, и объекты сохраняли бы состояние в немного более удобочитаемом формате.

На самом деле, однако, это вступает в обсуждение стиля кодирования. Ваш метод работает, и он не особенно неэффективен. Просто убедитесь, что код читаем, инкапсулирован и расширяем, и все будет в порядке.