Java pojo - переработка кэшированных значений Hashtable после повторения сбора новых данных - PullRequest
Новая
       18

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

1 голос
/ 08 февраля 2011

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

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

Теперь, хотя я могу загрузить изображение, возникает проблемав том, как кэшировать данные изображения таким образом, чтобы при получении нового набора объектов MyImage я сопоставлял их с моим кешем и сохранял изображение для этого объекта MyImage, только если оно уже было загружено.Другими словами, когда я сохраняю загруженное изображение в кэш Hashtable, я записываю данные изображения с созданным 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 && 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;
 }

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

Ответы [ 2 ]

0 голосов
/ 08 февраля 2011

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

imgs.keySet().retainAll(stillValidKeys);

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

0 голосов
/ 08 февраля 2011

FOLLOWUP

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

    // 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.

...