- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
if (s.contains("-"))
{
String[] sa = s.split("-", 2);
for (Long i = Long.parseLong(sa[0].trim()); i<=Long.parseLong(sa[1].trim()); i++)
{
departmentsQueue.add(i);
}
}
else
{
Long id = Long.parseLong(s.trim());
departmentsQueue.add(id);
}
Follow us!
1. А если "-" в начале строки...
2. Надеюсь, обработка исключений просто не вошла в пост.
3. Обязательно ли создавать объекты Long на каждый код подразделения?
Я бы в такой ситуации написал бы, наверное, простенький класс , который на вход принимает два элемента диапазона и проверяет, входят ли в диапазон определённые значения. Так можно в теории сэкономить кучу памяти. Жаль, что в java нет аналога [1..100500] из python/haskell.
2. В свете п. 1 исключений не должно возникнуть
3. А как Range использовать в данной ситуации?
Использовать его вместо очереди. Если нужна именно последовательность, можно реализовать тривиальный итератор по числам. Если уж выбрали Long, то, вероятно, числа содержат знаков эдак под 18. Если кодов подразделений меньше ста и они все небольшие, оно того не стоит.
Лепить здесь интервалы - это оверхед. Подразделений 100. Ну 1000 на худой конец. Да и в конфиге (а этот код как раз обрабатывает конфиги) обычно указывается не так много.
Пункт 1 покрывается пунктом 2 - исключения ловятся снаружи. Другое дело, что там ужаса много, формат ресурса не позволяет показать всего великолепия. Например, вот класс, откуда я скопировал фрагмент - это job для Quartz. Там с каждым запуском парсятся конфиги, поднимается JaxWsProxyFactoryBean, настраиваются параметры веб-сервиса, SSL и прочее. Я понимаю, что это делается раз в 4 часа. Но всё равно - нафига писать так криво? Более того, конфиги было бы оправданно парсить для возможности их горячей правки. Но фишка в том, что Properties загружается из файла пи запуске, а при каждом запуске задачи происходит загрузка списка подразделений указанным кодом. Ну и зачем в данном случае очередь, да ещё и потокобезопасная (тоже осталось за рамками фрагмента).
С Range я погорячился, да. Long смутил.
Да, вы правы, не ленивый. Однако же в этой ситуации его было бы удобно использовать.
Парсим на каждой итерации, что тут стесняться то.
Просто в этой фразе читался намек на плохую производительность.
А с читаемостью тут конечно не фонтан =)
Просто меня всегда удивляют такие вот оптимизации, типа сложения строк, или парсинга чисел, которые чаще всего дают практически незаметный рост производительности. Рост есть, но толку от него никакого.