410013796724260
• Webmoney
R335386147728
Z369087728698
Советы программирования : valueOf vs new, instanceOf, generic, поддержка ПОДанная страница является продолжением знакомства разработчиков ПО с коллекциями практик и советов программирования. В статье рассмотрены следующие вопросы : Поддержка и сопровождение ПОПрограммное обеспечение, перешедшее из стадии РАЗРАБОТКИ в стадию ПОДДЕРЖКИ, часто сопровождается небольшими, а порой крупными доработками, связанными как с «отловом ошибок», так и расширением функциональных свойств. Как правило, техологический процесс создания ПО включает репозиторий коллективной разработки типа git/svn, который хранит изменения всех предыдущих версий. Кроме этого, для учета всех задач отслеживания ошибок и управления проектом/ами в компании «используется» Jira Software.
А теперь представим ситуацию, что для ПО, находящегося в стадии СОПРОВОЖДЕНИЯ, один или несколько программистов создают
дополнительный функционал. И вот, в самый интересный момент приходит сообщение, что нужно что-то исправить в текущей
версии. То есть, необходимо срочно приложение «commit'еть» и откатываться назад. Далее следует «плести» ветви в
репозитории, вносить изменения в предыдущий код, а после передачи обновленной версии выполнять слияние ветвей. И это не
очень приятный процесс разработки, который программисты не очень приветствуют, как документирование кода.
Совет : при разработке нового функционала используйте логический флаг (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>. |