Java pojo — переработка кэшированных значений хэш-таблицы после итерации по новому сбору данных

#java #arrays #hashtable #enumeration #pojo

#java #массивы #хэш-таблица #перечисление #pojo

Вопрос:

Итак, да, я просто пытаюсь посмотреть, есть ли более элегантный способ сделать то, что я собираюсь сделать ниже (пожалуйста, имейте в виду, что я хочу ответы, связанные с POJO (обычными старыми объектами Java), поскольку эта проблема связана с J2ME, поэтому никаких обобщений и современных структур данных нет только в Java 1.5 и выше):

Предположим, у меня есть объект myImage, который является простым bean-объектом, который заполняется данными из сетевого вызова на мой сервер. Все, что он содержит, это метаданные об указанном изображении, относящиеся к моему приложению, что более важно, он содержит уникальный идентификатор, который используется для создания URL-адреса для извлечения изображения с моего сервера для этого объекта. Я получаю новый набор этих объектов время от времени, когда я делаю запрос на них, некоторые из которых совпадают с предыдущими запросами.

Теперь, даже если я могу загрузить изображение, проблема возникает в том, как кэшировать данные изображения таким образом, чтобы при получении нового набора объектов myImage я сопоставлял их со своим кэшем и сохранял изображение для этого объекта myImage только в том случае, если оно уже было загружено. Другими словами, когда я сохраняю загруженное изображение в свой кэш хэш-таблицы, я добавляю к данным изображения сконструированный URL (MY_IMAGE_SERVER myImageUniqueId). Когда я получаю новый набор объектов myImage, в настоящее время я делаю следующее:

  Hashtable imgs = getImages();

 //If we have cached images, we should see which ones to carry over.
 if(imgs.size() > 0){       
    Hashtable newImgs = new Hashtable();
    for(int i = 0; i < myImages.length; i  ){
        MyImage mi = myImages[i];
        if(mi != null amp;amp; mi.hasImage()){
            //Check if we have the MD5 URL
            if(imgs.containsKey(IMG_URL_PATH   mi.getUniqueId())){
                //Place in new hashtable
                newImgs.put(IMG_URL_PATH   mi.getUniqueId(), imgs.get(IMG_URL_PATH   mi.getUniqueId()));
            }
        }
    }
   _bannerImgs = newImgs;
 }
  

Мне интересно, звучит ли это законно, или это можно сделать лучшим, более эффективным способом?

Ответ №1:

ПРОДОЛЖЕНИЕ

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

     // Check if we have the image in our cache
    String key = IMG_URL_PATH   mi.getUniqueId();
    Object image = imgs.get(key);
    if (image != null) {
        // Carry over to new cache
        newImgs.put(key, image);
    }
  

Примечание:

  1. Создание / использование локальной переменной позволяет избежать создания ключевой строки 3 раза.
  2. Использование get вместо contains устраняет один поиск по хэш-таблице.

Однако сомнительно, что это существенно повлияет на производительность вашей системы … если только getUniqueId() метод не делает что-то глупое, например, вычисляет сумму MD5 при каждом его вызове. (И, по-видимому, это не так.)

Несмотря на производительность, я бы внес это изменение, потому что это облегчает чтение кода … IMO.

Комментарии:

1. код заменяет старый кэш новым кэшем, который содержит только изображения, подлежащие сохранению. итак, это сокращение старого кэша.

2. К вашему сведению, значения для UniqueID заранее определены и установлены в камне, все эти вычисления выполняются на серверной части для каждого возвращаемого изображения.

Ответ №2:

если у вас уже был набор, содержащий ключи изображений для сохранения, то вы могли бы просто сделать что-то вроде:

 imgs.keySet().retainAll(stillValidKeys);
  

однако, если все, что у вас есть, это список, то вашего текущего кода, вероятно, достаточно.

Комментарии:

1. К сожалению, поскольку J2ME / CLDC использует простую и более старую версию Java, поддержка Set objects отсутствует, так что эта функция не будет работать в моем случае.