Какой принцип SOLID нарушен в коде?

Опишите процесс создания экземпляра класса

Сначала класс и цепочка его предков должны быть загружены, сверху вниз. Рассмотрим ClassLoader и процесс загрузки классов в будущих постах. Здесь важно сказать, что класс загружается только один раз, при первом к нему обращении в рамках одного класслоадера.

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

Далее инстанциируется сам экземпляр. Как и с загрузкой классов, процесс выполняется для всей цепочки наследования, с самого дальнего родителя:
1. Выделяется память в куче для экземпляра, получается ссылка на этот экземпляр;
2. Выполняются инициализации нестатических полей и блоков инициализации в порядке объявления;
3. Вызывается конструктор;

Статические поля интерфейсов не инициализируются при создании объекта, а другого состояния интерфейс не имеет – это исключает вопрос порядка инициализации предков при множественном наследовании.

В процессе конструирования объекта может возникать проблема виртуального вызова в конструкторе, свойственная для многих языков. Effective Java Item 17 рекомендует не использовать переопределяемые методы в расширяемом классе. Иллюстрация неочевидного поведения в результате приведена выше на картинке

Java Guru🤓 #java

new Integer(128) == 128?

Для всех классов-оберток над примитивами кроме Float и Double работает механизм кэширования. Некоторые значения создаются на этапе инициализации класса, и переиспользуются когда объект создается не оператором new (например с помощью valueOf).

Кэшируемые значения – оба возможных Boolean, Character до '\u007f' (127) и все целые числа от -128 до 127 включительно. С Java 7 верхнюю границу для Integer можно увеличить параметром java.lang.Integer.IntegerCache.high.

Значения кэшируются и во многих других встроенных классах: BigDecimal, Currency, пустые коллекции. Детали можно узнавать из исходников и документаций, так как эти кэши реализованы не на уровне JVM а в коде классов.

В конкретно этом примере скрыт еще один подвох: объект класса-обертки сравнивается с примитивом. Это приводит к анбоксингу и сравнению значений. И ответ на вопрос – да.

Java Guru🤓 #java

Что такое enum?

enum – тип-перечисление. Бывает много разных формулировок вопроса, все они сводятся к разговору о перечислениях вообще. Технически это финальный класс со статическими финальными полями-экземплярами. enum Foo всегда неявно наследуется от Enum<Foo> – то есть перечислением нельзя расширить другой класс, но всё еще можно реализовать интерфейсы. Из-за generic-параметра разные перечисления не имеют общего предка кроме Object.

Является Comparable (сравнивается позиция по порядку объявления значений) и Serializable (сериализуется только имя константы).

Имеет только заранее заданный набор значений. Значения неявно public static final и это нельзя переопределить. Для инициализации констант действуют все правила статической инициализации.

Копии элементов перечисления не создаются даже при десериализации. Вот почему Effective Java предлагает использовать для сериализуемого синглтона enum.

Экземпляры хранят свойства name и ordinal – имя и порядковый номер константы. Статический метод values вернет список всех констант, valueOf – константу по имени. Спецификация.

Финализация и клонирование перечислений запрещены.

Java Guru🤓 #java

Зачем нужен загрузчик классов?

В Java используется динамическая загрузка классов. Ее выполняют загрузчики – наследники абстрактного класса ClassLoader. Кроме того, они же загружают и файлы-ресурсы.

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

Вручную класс можно загрузить из конкретного загрузчика, передав аргументом его метода loadClass бинарное имя класса.

В URLClassLoader и стандартных загрузчиках JVM источником класса служит .class-файл. Другие загрузчики в своей реализации используют и другие источники: это может быть сетевой ресурс, или класс может генерироваться в рантайме. К примеру загрузчик из javassist специализируется на создании классов на лету.

В результате загрузки создается экземпляр класса Class. В отличие от обычных объектов, такие экземпляры хранятся не в куче, а в permgen/metaspace. Class может быть выгружен, когда загрузивший его ClassLoader стал мусором.

Java Guru🤓 #java

Чем отличается перегрузка от переопределения?

Полиморфизм – соль ООП. Перегрузка (overload) и переопределение (override) – два инструмента достижения полиморфного поведения в Java.

Перегрузкой реализуется ad-hoc-полиморфизм. Это значит «один и тот же» метод может работать с разными параметрами. С технической точки зрения это просто два разных метода, сигнатуры которых имеют одинаковое название, но разный набор параметров. Важно помнить, что для перегрузки не достаточно различий только модификаторов, возвращаемых типов и списков исключений.

Ad-hoc – не совсем настоящий полиморфизм, так как при нём используется раннее, или статическое связывание (early binding, static dispatch). Это значит, что для выбора конкретного варианта метода используется информация о типе переменной, а не объекта в ней лежащего, и происходит это еще при компиляции.

Если в классе объявлены два перегруженных метода, а аргумент в вызове подходит под оба, случится ошибка компиляции. В примере выше компилятор не может выбрать между вариантами метода println с параметром char[] и со String, так как null может быть и тем и другим.

Переопределение (override) дает полиморфизм подтипов. Это реализация/подмена метода нефинального родительского класса или интерфейса. С помощью этого механизма достигается поведение, когда экземпляр хранится под типом родителя, но реализация методов используется специфичная для этого конкретного подтипа. Пример:
List<String> list = new LinkedList<>();
list.add(“foo“);


Здесь метод add вызывается общий для всех списков, но добавлен будет именно элемент связного списка.

Выбор конкретного метода происходит в последний момент, в процессе работы программы, в зависимости от типа объекта. Это называется позднее или динамическое связывание методов (late binding, dynamic dispatch).

Переопределение имеет непосредственное отношение к принципу подстановки Лисков (LSP): в хорошем объектно-ориентированном коде для вызывающего кода переопределенный метод не должен быть отличим от оригинального.

Переопределенный метод принято снабжать аннотацией @Override. Ее отсутствие допускается, но компиляция не перегружающего метода с такой аннотацией приведет к ошибке.

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

Статические методы нельзя переопределить, можно только перегрузить.

Java Guru🤓 #java

Когда Class.getClassLoader вернет null?

Этот вопрос поднимает две темы. Первая – класс Class в целом. Экземпляры Class<T> представляют runtime-описание типов. В терминах этого описания перечисления считаются классами, аннотации – интерфейсами. В основном приходится взаимодействовать с метаклассами при работе с рефлексией или загрузчиками.

По большей части эти экземпляры класса Class состоят из содержимого .class-файла. Создаются они только внутри класслоадера. Особенности их хранения в памяти обсуждаются в предыдущем посте.

Вторая тема для разговора здесь – особенности класса Class для примитивов, массивов и void. Для получения таких экземпляров используется тот же синтаксис, что и для обычных классов: void.class, int.class, float[][].class. Конструкция foo.class – это не обращение к члену, а литерал класса.

Для void типом-параметром T выступает специальный неинстанциируемый тип java.lang.Void. Тип-параметр примитива – соответствующий класс-враппер. Хотя для самого класса-враппера будет отдельный экземпляр Class. То есть int.class != Integer.class.

Метод getClassLoader обычного класса или интерфейса вернет загрузчик, который его загрузил. null может вернуться для загруженного bootstrap-класслоадером типа. Для массива возвращается то же, что для типа его элементов. Для примитивов и void результатом всегда будет null.

Java Guru🤓 #java

Как узнать, является ли A подтипом B?

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

instanceof – бинарный оператор, самый быстрый и самый используемый. Если есть экземпляр A и можно указать B явно, выбирать надо его. Если A (точнее тип хранящей экземпляр A переменной) и B не из одной цепочки наследования – экземпляр точно не может быть подтипом B и компиляция упадет с ошибкой inconvertible types.

Class::isInstance – метод принимает параметром объект типа A. Его стоит выбрать, когда экземпляр A в наличии, но B – неизвестный на этапе компиляции тип. То есть, для переменных A a и Class bClass, можем проверить bClass.isInstance(a).

Class::isAssignableFrom – принимает Class<A>. Единственное, что остается, если экземпляра A нет. bClass.isAssignableFrom(aClass).

Есть еще четвертый способ – имея экземпляр типа A привести его к B. Если типы были несовместимы, приведение выбросит ClassCastException. Это во всех смыслах плохой способ, построению логики программы на исключениях нет оправдания. Подробная аргументация описана в Effective Java Item 57.

Java Guru🤓 #java

Что вернётся, если отправить GET-запрос на /test?

В чём отличия интерфейса от абстрактного класса?

Главное отличие – это семантика. Интерфейсы появились еще до Java, как важная концепция ООП. Смысл интерфейса – некое поведение, описание свойства. Причем если придерживаться принципа сегрегации интерфейсов, это описание единственного аспекта поведения.

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

Отсюда вытекает естественность и необходимость множественного наследования для интерфейсов. Опыт таких языков как C++ показал, что множественное наследование классов не нужно и проблемно (см. проблема ромбовидного наследования). По факту же обычно нужно всего лишь переиспользование кода, что не относится к ООП и реализуется в некоторых языках «интерфейсами с независимым состоянием» – примесями.
В Java интерфейс в отличие от абстрактного класса не может иметь состояния. Реализация поведения же допустима только в двух случаях: для статических методов, и default для обычных. Статические методы являются частью всего класса, а не экземпляров. Дефолтная реализация, как говорилось ранее, добавлена только как хак для сохранения совместимости.

В интерфейсах, как публичных описаниях, не имеют смысла и запрещены непубличные члены. Отсюда синтаксическое отличие: модификатор public, как и abstract для методов или static для полей, можно не писать. Запрещены и модификаторы, несовместимые с abstract: final, synchronized и прочие.

На уровне скомпилированного байткода тоже есть небольшие различия: интерфейс помечается флагом ACC_INTERFACE а для класса генерируется конструктор по-умолчанию.

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

Java Guru🤓 #java

Что будет результатом запуска кода?