8 июня 2023 839
Этой публикацией мы начинаем серию небольших статей с разбором “сложных” заданий из сертификации для Java-разработчиков, чтобы помочь вам подготовиться к сдаче сертификационного экзамена и помочь вам лучше понять, как работает Java и как эффективнее использовать его в своих проектах.

Итак, один из подвопросов, традиционно выносимых на экзамен – будь это сертификация Oracle или сертификации для Java-разработчиков от Учебного центра IBS – интересуется разработкой кода с использованием классов-оболочек, в частности, Boolean, Double или, скажем, Integer. Такая задача может быть сформулирована в следующей форме:

photo_2023-06-05_10-27-43.jpg

Как мы видим, в вопросе задействованы два класса-оболочки, а именно Boolean (в лице его статического фабричного метода) и Integer. Следует отметить, что для нашего экзамена характерен подход, сочетающий в себе сразу несколько тестируемых аспектов. Поэтому не всегда очевидно, чем именно задача интересуется: тем, как работают "фабрики", механизмом автоупаковки/распаковки или оператором сравнения и т. д.

Обсудим все по-порядку. Практически в каждом классе-оболочке есть два популярных статических метода для создания объекта: valueOf(), который принимает подстилающий примитив, и parseXXX(), который – как и всякий парсер – принимает стринг (здесь вместо XXX надо подставить, например, Double, Int и т.д.). Исключением является класс Character: в нем парсера нет. Встречаются и перегруженные парсеры, где можно указать систему счисления, но наш экзамен таких тонкостей не касается.

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

Мы знаем, что при вызове конструктора через ключевое слово new возможны два результата: мы получим совершенно новый объект данного типа, либо вылетит исключение. Из-за такой ограниченности функционала конструкторов предпочтение отдается фабричным методам, которые – в отличие от любого конструктора – способны вернуть ссылку на уже существующий объект.

И вот что интересно: поскольку класс-оболочка Integer является немутирующим, два объекта этого класса с одним и тем же значением способны взаимозаменять друг друга. Вот почему нет никакой необходимости иметь два разных объекта с одинаковым подстилающим значением. Мало того, помимо экономии памяти мы получаем также возможность сравнивать объекты через == вместо вызова метода equals(Object o). В частности, для класса Integer такой подход популярен с объектами, чьи значения лежат в пределах диапазона байта, т.е. от -128 до 127. (И если тут возникает ощущение дежа-вю, то все правильно: со стрингами аналогичная история, мы предпочитаем пользоваться строковыми константами в двойных кавычках вместе вызова, скажем, new String("5").

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

В книге Джошуа Блока, "Effective Java", приведен полный список преимуществ статических фабричных методов над конструкторами. Еще одна выгода в том, что конструктор способен вернуть объект одного типа, а вот фабричный метод может вернуть что угодно, если это не противоречит задекларированному типу возвращаемого значения. Одно из наиболее наглядных и понятных проявленией – это имплементация интерфейсов, где можно аккуратно скрыть специфические детали реализации.

Метод Boolean.valueOf()может вернуть одно из двух значений, причем это константные объекты, а именно, Boolean.TRUE и Boolean.FALSE. Именно эти объекты будут использоваться раз за разом, не требуя дополнительного выделения памяти, что не представляется возможным с ключевым словом new.

Далее, большинство оболочечных классов бросают исключение в случае null-аргумента или стринга, чей формат нарушает требования к подстилающему примитиву (например, если бы мы вызвали Integer.valueOf() с аргументом "five", а не "5"). Но здесь следует отметить, что парсер класса java.lang.Boolean всегда тестирует аргумент: во-первых, существует ли он и, во-вторых, содержит ли значение "true" при любом сочетании букв в верхнем и нижнем регистрах. Если да, булевый парсер вернет Boolean.TRUE, а в противном случае – Boolean.FALSE. Другими словами, парсеру можно скормить хоть "что угодно", хоть даже null – и он просто вернет Boolean.FALSE без вылета какого-либо исключения.

Вот почему строка Х в нашем примере не бросает исключение и присваивает переменной boo значение Boolean.FALSE. Следовательно, вариант A не верный.

Теперь давайте займемся поведением оператора if. Мы знаем, что тестируемое выражение обязано иметь тип boolean. Привыкнув к механизму автоупаковки и распаковки, мы ожидаем, что Boolean-объект будет транспарентно распакован в подстилающий примитив. Так оно и случится, поэтому код скомпилируется – но из-за того, что наш экзамен рассчитан на Java11; до появления автоупаковки в Java5 эта же строчка вызвала бы синтаксическую ошибку. Впрочем, в нашей задаче вообще нет такого варианта.

После распаковки булевый тест получит значение false и, стало быть, оператор печати не исполнится. Что ж, выходит, вариант D – единственный правильный.

А теперь давайте задумаемся над тем, что было бы, если бы булевый тест дал значение true.

Как мы знаем, Java предоставляет две идиомы сравнения. Одна из них является конструкцией, встроенной непосредственно в лексику языка: это оператор ==. Вторая идиома – а именно, метод equals(Object o) – предоставлена стандартной библиотекой и, будучи частью функционала класса java.lang.Object, доступна любому объекту. Она не делает ничего полезного и своим поведением не отличается от оператора "double equals", поэтому классам-наследникам предписывается по-своему решать, каким образом переопределить такое поведение. Метод equals() имеет интересный контракт из пяти пунктов, но в нашем примере он не используется, поэтому мы не будем обсуждать его; вместо этого давайте займемся оператором ==.

Мы знаем, что "double equals" принимает два операнда, точнее два выражения. Нюанс в том, что выражения могут иметь разные типы – и это различие сказывается на результате сравнения самым радикальным образом.

Что за разные типы? Это наши старые знакомые: примитивы (коих в Java восемь: boolean, byte, short, char, int, long, float и, наконец, double), либо то, что мы именуем термином ссылка (reference). Напомним, что ссылка в Java напоминает указатель (pointer), который показывает, где именно в памяти расположен тот или иной объект.

Если выражение выражение имеет примитивный тип, то это бинарная репрезентация некоего числа, например, 0b101010, то есть, десятичное 42. Это число будет записано в стеке и ему будет присвоена некая метка, которую мы привыкли называть словом "переменная". Но вот если речь идет не про примитив 42, а про Integer-объект, который инкапсулирует подстилающий примитив 42, то в стеке будет сидеть уже не 0b101010, а нечто куда более "вихрастое", например, 0xffff5637. Эта комбинация шестнадцатиричных литералов по сути является значением ссылки на объект, который в языке Java живет не в стеке, а в т.н. динамически аллоцируемой памяти, в знаменитой "куче" (heap). К примеру, в языке C/С++, прородителе Java, значением пойнтера является адрес объекта. В Java ситуация несколько сложнее, но в первом приближении мы тоже можем сказать, что значением ссылки (которая живет в стеке) является адрес объекта (который, напомним, живет на heap'е). Что в итоге? Пусть оператор "double equals" сравнивает значения двух переменных. Если это примитивы, JVM сравнит их бинарные значения, то есть – числа. Если это ссылки, то JVM сравнит их значения, но ведь значением ссылки является адрес того объекта, на который данная ссылка указывает. Вот почему принято говорить, что оператор == проверяет эквивалентность примитивных значений, а в случае ссылок он сравнивает уже идентичность объектов. Если у двух ссылочных переменных (например, класса Integer) одно и то же значение, мы имеем дело с одним и тем же объектом (один и тот же адрес!), но если объектов два, то они расположены по разным адресам. В этой ситуации оператор == вернет false.

Сейчас не должно вызывать удивление, что данный код:

photo_2023-06-05_13-58-36.jpg

обязательно покажет false: ведь успешный вызов конструктора через new, как мы уже упоминали, приведет к рождению очередного объекта. Простое правило на нашем экзамене: сколько видим слов new, как минимум столько же будет объектов. Стало быть, переменные v1 и v2 по необходимости ссылаются на разные объекты, и сравнение их адресов оператором == даст нам false.

А вот небольшая вариация на эту же тему: пусть у нас такой код:

уцкуц.jpg

Опять мы видим new и это означает, что у нас вновь два разных объекта: один родился благодаря стараниям конструктора, а второй прилетел к нам из статического фабричного метода, который был вызван имплицитно и полностью для нас транспарентно был вызван механизмом автоупаковки.

В заключение следует отметить, что фабрики для немутирующих объектов часто пишутся так, чтобы возвращать все тот же объект, если в метод были переданы те же аргументы. В частности, в документации на java.lang.Integer API мы видим следующую ремарку о методе valueOf(int):

“This method will always cache values in the range -128 to 127, inclusive, and may cache other values outside of this range.”

Другими словами, следующий кодовый сниппет:

Integer v1 = Integer.valueOf(1);

Integer v2 = Integer.valueOf(1);

System.out.print(v1 == v2);

даст нам true.

Официально задокументированная гарантия присутствует лишь для метода valueOf(int), хотя на практике valueOf(String)также демонстрирует это же поведение: Integer-объекты в пределах диапазона байта помещаются в константный пул.

Подведем итоги: поскольку код пользуется механизмом автоупаковки (в форме вызова Integer.valueOf(int)для создания одного объекта, а для второго применяет вызов конструктора, это означает, что если бы отработал оператор печати, мы бы увидели false. Поэтому правильным вариантом ответа остается D, о чем мы уже упоминали.

Последние статьи в блоге

Сквозная логика: от бизнес-процесса к реализации без потерь

Главный принцип работы с проектной документацией — поддерживать её связность и актуальность. Любая, даже самая детальная схема (BPMN, Use Case, C4), мгновенно теряет ценность, если она конфликтует с другой. Узнаёте? Сначала все силы бросают на «личный кабинет», но после пары спринтов главным внезапно становятся «возвраты». В результате возникает опасный разрыв: цели проекта, реализуемый функционал и схемы, которые должны их описывать, живут своей жизнью. Документация превращается в «мёртвые зоны», которые больше не отражают реальность.

29 августа 2025

Заказная разработка ПО в IBS: безопасная разработка и доставка

В этой статье начальник отдела DevOps компании IBS Артур Галеев расскажет об опыте внедрения принципов безопасной разработки, используемых инструментах и нормативных актах, на которые стоит опираться.

Новости
26 августа 2025

Сертификация ИТ-специалистов: точная оценка ваших компетенций

В ИТ-мире важно не просто обладать знаниями, но и четко понимать свой реальный уровень владения теми или иными навыками.

Новости
22 августа 2025

Группа компаний IBS запускает национальную сертификацию для бизнес-аналитиков

Центр сертификации IBS запускает новую систему оценки квалификации бизнес-аналитиков, которая сочетает международные стандарты c особенностями российского рынка. Программа ориентирована на теоретическую базу и прикладные навыки, необходимые в работе бизнес-аналитика в современных ИТ- и цифровых проектах.

Жизнь компании
20 августа 2025

От разработчика к тренеру: как превратить экспертизу в стабильный доход

Часто к преподаванию переходят после достижения «карьерного потолка»: на уровне сеньора процессы отлажены, и новые вызовы исчезают. Однако вместо того чтобы долго преподавать за символическую плату, можно сосредоточиться на создании системного заработка. Разберём реальные способы: от коучинга до запуска курсов.

Новости
13 августа 2025

Установка и настройка брокера сообщений Kafka на Windows

Цель задания: научиться устанавливать и настраивать Apache Kafka на операционной системе Windows, а также выполнять базовые операции с топиками и сообщениями.

21 июля 2025

Почему Python? Полный разбор Python vs Java в ML

«Когда 9 из 10 курсов по машинному обучению используют Python — это не случайность. Это результат десятилетия эволюции инструментов, сообщества и образовательной экосистемы».

21 июля 2025

Что должен знать и уметь архитектор ПО в 2025 году

Представьте профессию, в которой нужно одновременно мыслить как инженер, говорить как консультант и чувствовать бизнес как продакт. Архитектор ПО — это не просто старший разработчик с модным названием должности, а человек, который соединяет технологии, людей и цели в устойчивую, масштабируемую систему. Но какими навыками он должен владеть сегодня, чтобы быть действительно востребованным?

21 июля 2025

Памятка по документированию архитектурных решений

Отсутствие качественного архитектурного описания в сложных ИТ-проектах создает серьезные риски: фрагментированное понимание системы, накопление «архитектурного долга», трудности интеграции, масштабирования и онбординга. Это ведет к срывам сроков, перерасходу бюджета, снижению качества и росту затрат на поддержку, подвергая проект риску неоптимальных решений и критических уязвимостей.

Новости
18 июля 2025

Летняя акция: учитесь онлайн с выгодой, не выходя из отпуска! До конца августа второй курс со скидкой 50%

Проведите лето с пользой для карьеры – второй курс со скидкой 50%!

09 июля 2025

5 курсов июля со скидкой 30%

Друзья, у нас остались последние места на курсах, которые стартуют в июле. Сейчас есть возможность записаться на обучение со скидкой 30%!

Новости
04 июля 2025

Карьерный трек аналитика: от базы к экспертизе

Системные и бизнес-аналитики аналитики играют ключевую роль в digital-развитии продуктов. Эти специалисты выступают связующим звеном между бизнес-задачами и техническими решениями, обеспечивая эффективную коммуникацию между заинтересованными сторонами. Рассмотрим карьерные пути в аналитике, актуальные требования рынка и перспективы профессионального роста.

27 июня 2025

Почему именно сейчас стоит учиться на бизнес-аналитика уровня Middle. «Руководство BABOK» в подарок участникам программы!

Вы в ИТ, вам за 30. Вроде бы всё хорошо — есть работа, скиллы, стабильность. Но в воздухе — тревожность. Проекты замораживаются. Бизнес урезает бюджеты. От ИТ ждут не просто задач, а конкретного влияния на прибыль.

25 июня 2025

Уничтожит ли ИИ-генератор кода профессию разработчика?

С появлением ИИ-инструментов, а также в связи недавним анонсом Canva Code, который генерирует код за пару кликов, многие задумались: не станут ли такие инструмент угрозой для разработчиков? Давайте разберемся, есть ли здесь реальные риски, или это все же преувеличения.

23 июня 2025

Проектное резюме консультанта 1С: карьерный инструмент, чтобы выделиться среди других кандидатов

Рассказываем о продвинутой альтернативе привычного резюме для консультантов 1C и других специалистов с проектной занятостью.

Новости
19 июня 2025

Выбор карьеры: Менеджер бизнес-процессов или Бизнес-аналитик уровня Middle?

В мире цифровой трансформации пути развития аналитиков и менеджеров проектов все чаще расходятся: кому-то ближе работа с требованиями и API, а кому-то — выстраивание системной эффективности на уровне всей компании. Какой путь выбрать лично вам?

Новости
18 июня 2025

В Учебном центре IBS планируется запуск курсов по продуктам TData

Читайте о стратегическом соглашении TData и IBS и наших новых курсах

11 июня 2025

Компетенции бизнес-аналитиков: Junior и Middle в сравнении

В условиях динамично развивающейся ИТ-индустрии важно чётко понимать, какие навыки и знания необходимы для успешной работы на каждом этапе карьерного пути. Сегодня обсудим разницу в компетенциях ИТ бизнес-аналитиков уровней Junior и Middle. Если вы только начинаете свой путь в ИТ бизнес-анализе или, наоборот, уже обладаете некоторым опытом, этот материал поможет вам понять, какие навыки необходимы на каждом уровне и как развиваться дальше.

Новости
05 июня 2025

Лимит на сбои. Как понять, что система перегружена, а не просто плохо сделана?

Оценить производительность системы непросто, а контролировать еще сложнее. Как сделать так, чтобы внедряемая или уже эксплуатируемая система справлялась с нагрузками? Можно ли в этом вопросе полностью положиться на разработчиков ПО или вендоров? И кто в итоге будет отвечать за все простои системы? Рассказывает Николай Марченко, директор отделения нагрузочного тестирования компании IBS. Начать следует с того, что разбираться с последствиями возможных сбоев в любом случае придется тем, кто работает непосредственно с системой. Поэтому о вопросах производительности лучше задуматься еще на этапе внедрения.

Новости
03 июня 2025

Кто такой аналитик 1С?

Аналитик 1С — это специалист, который занимается оптимизацией бизнес-процессов с использованием программного обеспечения 1С. Его задача — анализировать существующие процессы, выявлять недостатки и разрабатывать решения для повышения эффективности. Аналитик переводит бизнес-требования в технические задания для разработчиков, становясь мостом между пользователями и ИТ-отделом. Эта роль требует как технических знаний, так и навыков коммуникации, что позволяет вносить значительный вклад в развитие компании и улучшение её конкурентоспособности.

Новости
28 мая 2025

Не нашли, что искали? — Просто напишите, и мы поможем

Корпоративное обучение Оценка персонала Сертификация О нас Стань тренером Блог
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.