Афоризм
Гляжу, Вы лирик с матерным уклоном.
Наталья Резник
Последние статьи

 • Активности Android
Многоэкранные Android приложения
 • Fragment dynamic
Динамическая загрузка фрагментов в Android
 • Fragment lifecycle
Жизненный цикл Fragment'ов в Android
 • Fragment example
Пример Fragment'ов в Android
 • Data Binding
Описание и пример Data Binding
 • Пример MVVM
Пример использования MVVM в Android
 • Компонент TreeTable
Описание компонента TreeTable для Swing
 • Пример TreeTable
Пример использования TreeTable
 • Хранилища Android
Внутренние и внешние хранилища данных
 • Пример SQLite
Пример использования SQLite в Android
 • WebSocket
Описание и пример реализации WebSocket
 • Визуальные компоненты
Улучшен компонент выбора даты из календаря
 • Анимация jQuery
Описание и примеры анимации элементов DOM
 • APK-файл Android
Создание apk-файла для android устройств, .dex файлы
 • платформа JaBricks
Платформа OSGi-приложения JaBricks
Поддержка проекта

Если Вам сайт понравился и помог, то будем признательны за Ваш «посильный» вклад в его поддержку и развитие
 • Yandex.Деньги
  410013796724260

 • Webmoney
  R335386147728
  Z369087728698

Советы программирования : valueOf vs new, instanceOf, generic, поддержка ПО

Данная страница является продолжением знакомства разработчиков ПО с коллекциями практик и советов программирования. В статье рассмотрены следующие вопросы :

Поддержка и сопровождение ПО

Программное обеспечение, перешедшее из стадии РАЗРАБОТКИ в стадию ПОДДЕРЖКИ, часто сопровождается небольшими, а порой крупными доработками, связанными как с «отловом ошибок», так и расширением функциональных свойств. Как правило, техологический процесс создания ПО включает репозиторий коллективной разработки типа git/svn, который хранит изменения всех предыдущих версий. Кроме этого, для учета всех задач отслеживания ошибок и управления проектом/ами в компании «используется» Jira Software.

А теперь представим ситуацию, что для ПО, находящегося в стадии СОПРОВОЖДЕНИЯ, один или несколько программистов создают дополнительный функционал. И вот, в самый интересный момент приходит сообщение, что нужно что-то исправить в текущей версии. То есть, необходимо срочно приложение «commit'еть» и откатываться назад. Далее следует «плести» ветви в репозитории, вносить изменения в предыдущий код, а после передачи обновленной версии выполнять слияние ветвей. И это не очень приятный процесс разработки, который программисты не очень приветствуют, как документирование кода.

После того, как мне пришлось несколько раз объяснить мой подход к решению данной проблемы, я решил опубликовать этот совет. Так, к примеру, мне постоянно приходится использовать репозиторий git (раньше svn), но я очень не люблю создавать в них различные ветви. Не от того, что не умею, а просто не хочу. Считаю, что лучше я установлю некий флаг, связанный с задачей (TASK) в Jire; этот флаг можно легко сбросить и, тем самым, «откатиться» назад.

Совет : при разработке нового функционала используйте логический флаг (boolean), связанный с задачей, например boolean DEVELOPMENT_1234 = true. Все изменения в коде, определенные задачей Task-1234, «опоясывются» данным флагом :

public static boolean DEVELOPMENT_1234 = true;
. . .
if (DEVELOPMENT_1234) {
  // новая версия 
} else {
  // рабочая версия 
}

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

Таким образом, при сброшенном флаге у Вас будет рабочая версия, а при установленном флаге – новая, дорабатываемая версия.

valueOf vs new

Классы-оболочки примитивных типов целочисленных значений от Byte до Long имеют кэш, который, по умолчанию, содержит значения от -128 до 127.

// медленно
Integer i = new Integer(32);
Long    l = new Long(64);
String  s = new String("Comment");

// быстро
Integer i = Integer.valueOf(32);
Long    l = 64L; // тоже самое, что и Long.valueOf(64L);
String  s = "Comment";

Чтобы не попасть в ситуацию, когда Вам вернется значение из кеша, используйте в стандартных классах-оболочках примитивных типов метод valueOf вместо конструктора.

Оператор instanceOf

Оператор instanceOf является одним из самых медленных java операторов, старайтесь использовать его как можно реже. Полиморфизм почти всегда позволяет избавиться от этого оператора. В «облаке» иногда можно встретить упреки отдельных «гуру», что использование оператора instanceOf означает непонимание принципов ООП. Позвольте с ними не согласиться. Программист должен уметь решать различные задачи несколькими методами; желательно находить оптимальный. А временны́е затраты на исполнение оператора instanceOf далеко не всегда сопровождаются замедлением представления информации в интерфейсе.

P.S. Сравнивать по производительности различные операторы языка, выполняющих абсолютно разные задачи, не совсем корректно. Но иметь представление о технологии выполнения оператора виртуальной машиной JVM желательно, хотя бы на уровне временны́х затрат.

Обобщение типа, generic

При описании переменной типа коллекции старайтесь её типизировать. Это позволяет компилятору проверить тип на корректность во всем коде во время компиляции. Таким образом, приведение типа ("java casting") выполняется автоматически.

List<Integer> intList = new LinkedList<Integer>();
intList.add(Integer.valueOf(10)); 
Integer x = intList.iterator().next(); 

Использование generic избавляет сразу от двух потенциальных проблем: приведение типов и ошибок выполнения. Если же коллекция должна включать разнотипные обьекты, следует использовать <?>. Конечно же лучше, чтобы эти однотипные объекты имели бы одного «родителя»; в этом случае можно было бы применить <? extends someType>.

  Рейтинг@Mail.ru