Что можно делать с переменной хранящей null?
Во-первых, если переменная не финальная, использовать как L-value этого типа – присваивать новое значение.
Во-вторых, то же, что со значением null, но с учетом типа:
🔘 Сравнивать с null или переменной этого же класса;
🔘 Приводить к типу-родителю (upcast) или типу-наследнику (downcast), учитывая границы generic-параметров при наличии;
🔘 Обращаться к членам экземпляра и получать NullPointerException;
🔘 Применять instanceof и получать false
🔘 Использовать как параметр для методов и других совместимых с типом операторов
В-третьих, можно обращаться к статическим членам класса. В вопросе подразумевается именно эта интересная часть. Это безопасно, NullPointerException не возникнет, но для упрощения отладки и из-за отсутствия переопределения статических членов рекомендуется так не делать. Вместо этого обращайтесь к статике явно через имя класса, либо неявно, добавив для класса import static.
Во-первых, если переменная не финальная, использовать как L-value этого типа – присваивать новое значение.
Во-вторых, то же, что со значением null, но с учетом типа:
🔘 Сравнивать с null или переменной этого же класса;
🔘 Приводить к типу-родителю (upcast) или типу-наследнику (downcast), учитывая границы generic-параметров при наличии;
🔘 Обращаться к членам экземпляра и получать NullPointerException;
🔘 Применять instanceof и получать false
🔘 Использовать как параметр для методов и других совместимых с типом операторов
В-третьих, можно обращаться к статическим членам класса. В вопросе подразумевается именно эта интересная часть. Это безопасно, NullPointerException не возникнет, но для упрощения отладки и из-за отсутствия переопределения статических членов рекомендуется так не делать. Вместо этого обращайтесь к статике явно через имя класса, либо неявно, добавив для класса import static.
👍18❤2🔥1🍌1
Что такое enum?
enum – тип-перечисление. Бывает много разных формулировок вопроса, все они сводятся к разговору о перечислениях вообще. Технически это финальный класс со статическими финальными полями-экземплярами. enum Foo всегда неявно наследуется от Enum<Foo> – то есть перечислением нельзя расширить другой класс, но всё еще можно реализовать интерфейсы. Из-за generic-параметра разные перечисления не имеют общего предка кроме Object.
Является Comparable (сравнивается позиция по порядку объявления значений) и Serializable (сериализуется только имя константы).
Имеет только заранее заданный набор значений. Значения неявно public static final и это нельзя переопределить. Для инициализации констант действуют все правила статической инициализации.
Копии элементов перечисления не создаются даже при десериализации. Вот почему Effective Java предлагает использовать для сериализуемого синглтона enum.
Экземпляры хранят свойства name и ordinal – имя и порядковый номер константы. Статический метод values вернет список всех констант, valueOf – константу по имени. Спецификация.
Финализация и клонирование перечислений запрещены.
enum – тип-перечисление. Бывает много разных формулировок вопроса, все они сводятся к разговору о перечислениях вообще. Технически это финальный класс со статическими финальными полями-экземплярами. enum Foo всегда неявно наследуется от Enum<Foo> – то есть перечислением нельзя расширить другой класс, но всё еще можно реализовать интерфейсы. Из-за generic-параметра разные перечисления не имеют общего предка кроме Object.
Является Comparable (сравнивается позиция по порядку объявления значений) и Serializable (сериализуется только имя константы).
Имеет только заранее заданный набор значений. Значения неявно public static final и это нельзя переопределить. Для инициализации констант действуют все правила статической инициализации.
Копии элементов перечисления не создаются даже при десериализации. Вот почему Effective Java предлагает использовать для сериализуемого синглтона enum.
Экземпляры хранят свойства name и ordinal – имя и порядковый номер константы. Статический метод values вернет список всех констант, valueOf – константу по имени. Спецификация.
Финализация и клонирование перечислений запрещены.
👍15🔥5
Зачем нужен загрузчик классов?
В Java используется динамическая загрузка классов. Ее выполняют загрузчики – наследники абстрактного класса ClassLoader. Кроме того, они же загружают и файлы-ресурсы.
Загрузка класса (точнее любого ссылочного типа) и всех его предков происходит автоматически перед его инициализацией. При этом используется тот лоадер, который загрузил текущий код. Таким образом, загрузка всех, даже встроенных классов – ленивая.
Вручную класс можно загрузить из конкретного загрузчика, передав аргументом его метода loadClass бинарное имя класса.
В URLClassLoader и стандартных загрузчиках JVM источником класса служит .class-файл. Другие загрузчики в своей реализации используют и другие источники: это может быть сетевой ресурс, или класс может генерироваться в рантайме. К примеру загрузчик из javassist специализируется на создании классов на лету.
В результате загрузки создается экземпляр класса Class. В отличие от обычных объектов, такие экземпляры хранятся не в куче, а в permgen/metaspace. Class может быть выгружен, когда загрузивший его ClassLoader стал мусором.
В Java используется динамическая загрузка классов. Ее выполняют загрузчики – наследники абстрактного класса ClassLoader. Кроме того, они же загружают и файлы-ресурсы.
Загрузка класса (точнее любого ссылочного типа) и всех его предков происходит автоматически перед его инициализацией. При этом используется тот лоадер, который загрузил текущий код. Таким образом, загрузка всех, даже встроенных классов – ленивая.
Вручную класс можно загрузить из конкретного загрузчика, передав аргументом его метода loadClass бинарное имя класса.
В URLClassLoader и стандартных загрузчиках JVM источником класса служит .class-файл. Другие загрузчики в своей реализации используют и другие источники: это может быть сетевой ресурс, или класс может генерироваться в рантайме. К примеру загрузчик из javassist специализируется на создании классов на лету.
В результате загрузки создается экземпляр класса Class. В отличие от обычных объектов, такие экземпляры хранятся не в куче, а в permgen/metaspace. Class может быть выгружен, когда загрузивший его ClassLoader стал мусором.
🔥11👍5
👍15🔥6😢2❤1
Какие существуют стандартные загрузчики классов?
В JVM встроено как минимум три стандартных загрузчика:
🔘 Bootstrap – встроенная в JVM нативная реализация, родитель для всех остальных загрузчиков. Загружает часть стандартных классов java.*;
🔘 Platform – отвечает за загрузку стандартных классов Java-рантайма. До Java 9 назывался Extension и занимался загрузкой расширений. Гарантируется, что ему будут видны (но не факт что загружены непосредственно им) все стандартные классы Java SE и JDK;
🔘 System (Application) – загружает классы из classpath конкретного приложения;
Перед тем как загрузить класс, ClassLoader проверит, не может ли это сделать его родитель. Если класс уже загружен, то загрузка не потребуется.
Иллюстрация смысла этой иерархии – загрузчики web-сервера Apache Tomcat. Прикладной код каждого web-приложения работает на своем отдельном загрузчике изолированно от других приложений. Даже один и тот же класс-singleton у каждого приложения будет собственный. Системные классы и общие библиотеки при том грузятся их родительскими загрузчиками, только один раз для сервера.
В JVM встроено как минимум три стандартных загрузчика:
🔘 Bootstrap – встроенная в JVM нативная реализация, родитель для всех остальных загрузчиков. Загружает часть стандартных классов java.*;
🔘 Platform – отвечает за загрузку стандартных классов Java-рантайма. До Java 9 назывался Extension и занимался загрузкой расширений. Гарантируется, что ему будут видны (но не факт что загружены непосредственно им) все стандартные классы Java SE и JDK;
🔘 System (Application) – загружает классы из classpath конкретного приложения;
Перед тем как загрузить класс, ClassLoader проверит, не может ли это сделать его родитель. Если класс уже загружен, то загрузка не потребуется.
Иллюстрация смысла этой иерархии – загрузчики web-сервера Apache Tomcat. Прикладной код каждого web-приложения работает на своем отдельном загрузчике изолированно от других приложений. Даже один и тот же класс-singleton у каждого приложения будет собственный. Системные классы и общие библиотеки при том грузятся их родительскими загрузчиками, только один раз для сервера.
👍18❤1🔥1
Как написать синглтон?
Singleton – это паттерн проектирования «одиночка», класс с единственным экземпляром. Такая пространная формулировка открывает простор для подходов к реализации, а значит и для уточняющих вопросов, на которые и рассчитывает интервьюер.
Первое что надо выяснить – единственный экземпляр в рамках чего. В базовом случае уникальность объекта обеспечивается на уровне реализации класса. Но при этом базовом подходе создается по объекту на каждый класслоадер. Для уникальности на всю виртуальную машину реализацию нужно дополнить. Понадобится больше действий уже на уровне ОС чтобы добиться единого экземпляра между процессами JVM. С другой стороны, может требоваться специфичное для фреймворка сужение «области уникальности», например по экземпляру на каждый Spring IoC-контейнер.
Затем вы узнаете, должен ли быть ровно один экземпляр, или не больше одного. Проще говоря, должно ли его создание быть ленивым. Возможно время использования объекта ограничено внешними условиями, и позднее он должен быть утилизирован.
И наконец нужно уточнить, в каких обстоятельствах подразумевается его использовать. Обычно предлагают условие многопоточной среды – инстанцирование необходимо синхронизировать. Другое возможное требование – сохранение состояния от запуска к запуску. Спектр опций здесь ограничивается только фантазией собеседующего.
Singleton – это паттерн проектирования «одиночка», класс с единственным экземпляром. Такая пространная формулировка открывает простор для подходов к реализации, а значит и для уточняющих вопросов, на которые и рассчитывает интервьюер.
Первое что надо выяснить – единственный экземпляр в рамках чего. В базовом случае уникальность объекта обеспечивается на уровне реализации класса. Но при этом базовом подходе создается по объекту на каждый класслоадер. Для уникальности на всю виртуальную машину реализацию нужно дополнить. Понадобится больше действий уже на уровне ОС чтобы добиться единого экземпляра между процессами JVM. С другой стороны, может требоваться специфичное для фреймворка сужение «области уникальности», например по экземпляру на каждый Spring IoC-контейнер.
Затем вы узнаете, должен ли быть ровно один экземпляр, или не больше одного. Проще говоря, должно ли его создание быть ленивым. Возможно время использования объекта ограничено внешними условиями, и позднее он должен быть утилизирован.
И наконец нужно уточнить, в каких обстоятельствах подразумевается его использовать. Обычно предлагают условие многопоточной среды – инстанцирование необходимо синхронизировать. Другое возможное требование – сохранение состояния от запуска к запуску. Спектр опций здесь ограничивается только фантазией собеседующего.
👍21
Чем отличается interface от @interface?
Среди интерфейсов выделяется особая группа, которая не объявляет никаких методов. Пример такого интерфейса – Serializable. Такие интерфейсы добавляют классу некую семантику, которая позже используется либо с помощью рефлексии (и instanceof), либо вообще не программно, а как информация для разработчиков и инструментов разработки. Это маркерные интерфейсы. Маркерный интерфейс представляет метаинформацию класса.
Начиная с Java 1.5 в языке появился новый вид типов – аннотации. Они берут на себя и расширяют возможности маркерного интерфейса:
1. Можно применять аннотацию не только к классу или интерфейсу, но почти к чему угодно: к пакетам, к методам, их параметрам, переменным. Полный список представлен в перечислении ElementType;
2. Аннотация может нести данные в своих элементах
3. Аннотация может не присутствовать в рантайме, или даже остаться только в исходнике, не попав в байткод вовсе. Определяется ее RetentionPolicy;
4. Можно сделать аннотацию не наследуемой, просто не помечая ее @Inherited;
5. И конечно же, синтаксис. Примененная аннотация с первого взгляда отличается от настоящих интерфейсов.
Joshua Block в главе 37 Effective Java выделяет два преимущества маркерных интерфейсов перед аннотациями на этапе компиляции:
1. Можно требовать использование только маркированного параметра, так как маркерный интерфейс – это еще и тип;
2. Можно сузить применяемость маркера к только определенным типам, сделав интерфейс их наследником.
Возвращаясь к вопросу, ключевое слово @interface объявляет аннотацию, interface – интерфейс.
В результате компиляции в .class-файле аннотация превращается в интерфейс-наследник java.lang.annotation.Annotation, помеченный флагом ACC_ANNOTATION. Элементы превращаются в абстрактные методы. Этим объясняется синтаксис объявления. Специфичные для аннотаций атрибуты описаны в JVMS 4.7.16-4.7.22.
К слову, конструкции вида @something в javadoc называются тэгами. Они выглядят похоже на аннотации, также представляют метаинформацию для документации, но технически не имеют с ними ничего общего.
Среди интерфейсов выделяется особая группа, которая не объявляет никаких методов. Пример такого интерфейса – Serializable. Такие интерфейсы добавляют классу некую семантику, которая позже используется либо с помощью рефлексии (и instanceof), либо вообще не программно, а как информация для разработчиков и инструментов разработки. Это маркерные интерфейсы. Маркерный интерфейс представляет метаинформацию класса.
Начиная с Java 1.5 в языке появился новый вид типов – аннотации. Они берут на себя и расширяют возможности маркерного интерфейса:
1. Можно применять аннотацию не только к классу или интерфейсу, но почти к чему угодно: к пакетам, к методам, их параметрам, переменным. Полный список представлен в перечислении ElementType;
2. Аннотация может нести данные в своих элементах
3. Аннотация может не присутствовать в рантайме, или даже остаться только в исходнике, не попав в байткод вовсе. Определяется ее RetentionPolicy;
4. Можно сделать аннотацию не наследуемой, просто не помечая ее @Inherited;
5. И конечно же, синтаксис. Примененная аннотация с первого взгляда отличается от настоящих интерфейсов.
Joshua Block в главе 37 Effective Java выделяет два преимущества маркерных интерфейсов перед аннотациями на этапе компиляции:
1. Можно требовать использование только маркированного параметра, так как маркерный интерфейс – это еще и тип;
2. Можно сузить применяемость маркера к только определенным типам, сделав интерфейс их наследником.
Возвращаясь к вопросу, ключевое слово @interface объявляет аннотацию, interface – интерфейс.
В результате компиляции в .class-файле аннотация превращается в интерфейс-наследник java.lang.annotation.Annotation, помеченный флагом ACC_ANNOTATION. Элементы превращаются в абстрактные методы. Этим объясняется синтаксис объявления. Специфичные для аннотаций атрибуты описаны в JVMS 4.7.16-4.7.22.
К слову, конструкции вида @something в javadoc называются тэгами. Они выглядят похоже на аннотации, также представляют метаинформацию для документации, но технически не имеют с ними ничего общего.
👍14❤1
Когда 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.
Этот вопрос поднимает две темы. Первая – класс 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.
👍10🤔4
Что будет выведено на экран?
Anonymous Quiz
6%
5
45%
12
8%
0
10%
Ошибка времени выполнения
31%
Ошибка компиляции
👍14😢3🌭2❤1
📕 Книги для Java программиста - канал с книгами по Java. Постоянно выходят новинки как на русском так и на английском языке!
📰 Java News - канал с последними новостями из мира Java!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤3🔥2
Как узнать, является ли 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 доступны три способа проверки совместимости типов. Функционально они ничем не отличаются, применяются для разных наборов аргументов. В порядке убывания быстродействия:
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.
👍12🔥1
Что такое Reflection и как его использовать?
Reflection, рефлексия – это средства манипуляции данными на основе знания о структуре классов этих данных, инструменты метапрограммирования.
Класс Class<T> используется как точка входа в мир рефлекшена. Его экземпляры предоставляют саму метаинформацию о содержимом класса и основные методы для работы с ним. Все классы относящиеся Java Reflection находятся в пакетах java.lang и java.lang.reflect.
Экземпляр класса Class можно получить тремя способами:
🔘 Литералом .class;
🔘 Статическим фабричным методом Class.forName();
🔘 Методом getClass() экземпляров класса.
Использование Reflection API медленное и небезопасное. Оно позволяет ломать инвариантность состояний экземпляра, нарушать инкапсуляцию, и даже менять финальные поля.
Использовать рефлексию естественно в тестовом коде, в инструментах разработки, в фреймворках (особенно в связке с runtime-аннотациями). Рефлекшн в ординарном бизнес-коде обычно говорит о больших проблемах проектирования.
Нередко на интервью просят продемонстрировать пример использования рефлекшна. Один из самых близких для backend-разработчика примеров – инициализация классов-конфигураций в Spring Framework. Фреймворк с помощью рефлекшна сканирует внутренности таких классов. Поля и методы, помеченные специальными аннотациями, воспринимаются как объявления элементов экосистемы фреймворка.
Reflection, рефлексия – это средства манипуляции данными на основе знания о структуре классов этих данных, инструменты метапрограммирования.
Класс Class<T> используется как точка входа в мир рефлекшена. Его экземпляры предоставляют саму метаинформацию о содержимом класса и основные методы для работы с ним. Все классы относящиеся Java Reflection находятся в пакетах java.lang и java.lang.reflect.
Экземпляр класса Class можно получить тремя способами:
🔘 Литералом .class;
🔘 Статическим фабричным методом Class.forName();
🔘 Методом getClass() экземпляров класса.
Использование Reflection API медленное и небезопасное. Оно позволяет ломать инвариантность состояний экземпляра, нарушать инкапсуляцию, и даже менять финальные поля.
Использовать рефлексию естественно в тестовом коде, в инструментах разработки, в фреймворках (особенно в связке с runtime-аннотациями). Рефлекшн в ординарном бизнес-коде обычно говорит о больших проблемах проектирования.
Нередко на интервью просят продемонстрировать пример использования рефлекшна. Один из самых близких для backend-разработчика примеров – инициализация классов-конфигураций в Spring Framework. Фреймворк с помощью рефлекшна сканирует внутренности таких классов. Поля и методы, помеченные специальными аннотациями, воспринимаются как объявления элементов экосистемы фреймворка.
👍13🔥1
Обучение Java-разработке с постоплатой и гарантированное трудоустройство!
Учись сейчас – плати, когда устроишься на работу.
❗️Старт нового потока по Java от школы IT Mentor уже в сентябре. Срок обучения 6-8 месяцев.
Ворвись в сферу высокооплачиваемого IT с поддержкой в закрытом комьюнити профессионалов-коллег в течение 18 месяцев.
👉 Записывайся на курс https://www.it-mentor.tech/java?utm_source=tg&utm_medium=javatasks&utm_campaign=2023-08-29
Выпускники нашей школы уже на старте зарабатывают от 150 тыс.руб. Сможешь и ты!
Почему тебе точно нужно к нам?
✔️ Только актуальная инфа и востребованные стек текхнологий: Java Core, JDBC, HIBERNATE, SPRING (Core, MVC, Security), SPRING BOOT, GIT (GITHUB, GITLAB), MAVEN
✔️ Индивидуальная программа, заточенная под твой уровень знаний
✔️ Контроль знаний с обратной связью менторов
✔️ Работа на реальном проекте – при выпуске готовый кейс
✔️ Поддержка опытных менторов позволит подготовиться к собеседованиям и составить твое CVL, проведение тестовых собеседований - быть уверенным в результате.
✔️ Закрытое комьюнити с коллегами и чаты помогут оставаться в тренде.
Стань частью профессионального IT-сообщества!
А если хорошо знаешь английский, вообще nice 🔥! Для тебя есть опция - трудоустройство в иностранную компанию и возможность релокации зарубеж.
Кстати, если вообще решишь не работать, а чилить на диване 24/7 и не устроишься в IT - вообще ничего не должен! Этот пункт мы внесли в договор 💸 Поэтому ты вообще ничего не теряешь.
👉 Записывайся на курс https://www.it-mentor.tech/java?utm_source=tg&utm_medium=javatasks&utm_campaign=2023-08-29
Учись сейчас – плати, когда устроишься на работу.
❗️Старт нового потока по Java от школы IT Mentor уже в сентябре. Срок обучения 6-8 месяцев.
Ворвись в сферу высокооплачиваемого IT с поддержкой в закрытом комьюнити профессионалов-коллег в течение 18 месяцев.
👉 Записывайся на курс https://www.it-mentor.tech/java?utm_source=tg&utm_medium=javatasks&utm_campaign=2023-08-29
Выпускники нашей школы уже на старте зарабатывают от 150 тыс.руб. Сможешь и ты!
Почему тебе точно нужно к нам?
✔️ Только актуальная инфа и востребованные стек текхнологий: Java Core, JDBC, HIBERNATE, SPRING (Core, MVC, Security), SPRING BOOT, GIT (GITHUB, GITLAB), MAVEN
✔️ Индивидуальная программа, заточенная под твой уровень знаний
✔️ Контроль знаний с обратной связью менторов
✔️ Работа на реальном проекте – при выпуске готовый кейс
✔️ Поддержка опытных менторов позволит подготовиться к собеседованиям и составить твое CVL, проведение тестовых собеседований - быть уверенным в результате.
✔️ Закрытое комьюнити с коллегами и чаты помогут оставаться в тренде.
Стань частью профессионального IT-сообщества!
А если хорошо знаешь английский, вообще nice 🔥! Для тебя есть опция - трудоустройство в иностранную компанию и возможность релокации зарубеж.
Кстати, если вообще решишь не работать, а чилить на диване 24/7 и не устроишься в IT - вообще ничего не должен! Этот пункт мы внесли в договор 💸 Поэтому ты вообще ничего не теряешь.
👉 Записывайся на курс https://www.it-mentor.tech/java?utm_source=tg&utm_medium=javatasks&utm_campaign=2023-08-29
👍6
В чём отличия интерфейса от абстрактного класса?
Главное отличие – это семантика. Интерфейсы появились еще до Java, как важная концепция ООП. Смысл интерфейса – некое поведение, описание свойства. Причем если придерживаться принципа сегрегации интерфейсов, это описание единственного аспекта поведения.
Класс, даже абстрактный – это комбинация всех свойств и их реализаций, которыми определяются сущности некоторой категории (собственно, класса).
Отсюда вытекает естественность и необходимость множественного наследования для интерфейсов. Опыт таких языков как C++ показал, что множественное наследование классов не нужно и проблемно (см. проблема ромбовидного наследования). По факту же обычно нужно всего лишь переиспользование кода, что не относится к ООП и реализуется в некоторых языках «интерфейсами с независимым состоянием» – примесями.
В Java интерфейс в отличие от абстрактного класса не может иметь состояния. Реализация поведения же допустима только в двух случаях: для статических методов, и default для обычных. Статические методы являются частью всего класса, а не экземпляров. Дефолтная реализация, как говорилось ранее, добавлена только как хак для сохранения совместимости.
В интерфейсах, как публичных описаниях, не имеют смысла и запрещены непубличные члены. Отсюда синтаксическое отличие: модификатор public, как и abstract для методов или static для полей, можно не писать. Запрещены и модификаторы, несовместимые с abstract: final, synchronized и прочие.
На уровне скомпилированного байткода тоже есть небольшие различия: интерфейс помечается флагом ACC_INTERFACE а для класса генерируется конструктор по-умолчанию.
И есть еще одно небольшое отличие. Интерфейс с одним методом можно использовать как функциональный, и инстанциировать лямбда-выражением. Для абстрактного класса даже с единственным методом такое не сработает.
Главное отличие – это семантика. Интерфейсы появились еще до Java, как важная концепция ООП. Смысл интерфейса – некое поведение, описание свойства. Причем если придерживаться принципа сегрегации интерфейсов, это описание единственного аспекта поведения.
Класс, даже абстрактный – это комбинация всех свойств и их реализаций, которыми определяются сущности некоторой категории (собственно, класса).
Отсюда вытекает естественность и необходимость множественного наследования для интерфейсов. Опыт таких языков как C++ показал, что множественное наследование классов не нужно и проблемно (см. проблема ромбовидного наследования). По факту же обычно нужно всего лишь переиспользование кода, что не относится к ООП и реализуется в некоторых языках «интерфейсами с независимым состоянием» – примесями.
В Java интерфейс в отличие от абстрактного класса не может иметь состояния. Реализация поведения же допустима только в двух случаях: для статических методов, и default для обычных. Статические методы являются частью всего класса, а не экземпляров. Дефолтная реализация, как говорилось ранее, добавлена только как хак для сохранения совместимости.
В интерфейсах, как публичных описаниях, не имеют смысла и запрещены непубличные члены. Отсюда синтаксическое отличие: модификатор public, как и abstract для методов или static для полей, можно не писать. Запрещены и модификаторы, несовместимые с abstract: final, synchronized и прочие.
На уровне скомпилированного байткода тоже есть небольшие различия: интерфейс помечается флагом ACC_INTERFACE а для класса генерируется конструктор по-умолчанию.
И есть еще одно небольшое отличие. Интерфейс с одним методом можно использовать как функциональный, и инстанциировать лямбда-выражением. Для абстрактного класса даже с единственным методом такое не сработает.
👍29🔥3❤1☃1
Что если оба реализуемых интерфейса объявляют один и тот же метод?
Если объявление полностью одинаково – нет никакой проблемы, класс-реализация должен просто определить этот метод.
Когда у обоих интерфейсов объявлены методы с одинаковой сигнатурой, но разными возвращаемыми типами – всё зависит от того, какие именно эти типы.
Переопределение метода (override) еще с Java 5 ковариантно относительно возвращаемого типа. То есть, в наследнике тип результата метода может быть наследником: super метод возвращает Number, @Override метод возвращает Integer.
Если типы не связаны отношением наследования, например String и Long – такой класс невозможно реализовать.
Для примитивов никакой ковариантности возвращаемого типа нет. Даже если типы совместимы относительно присваивания: int→long, int→Integer. В любом из таких случаев будет ошибка о несовместимости возвращаемых типов, для примитивов они должны совпадать в точности.
Если различие в части throws, методы объявлены выбрасывающими разные типы исключений. Правила здесь те же, что для возвращаемых типов – работает ковариантность. Отличие лишь в том, что исключений примитивных типов не бывает, а даже для не являющихся родителем и наследником исключений всегда есть вариант, удовлетворяющий обоим – отсутствие выбрасываемых исключений вообще.
Если объявление полностью одинаково – нет никакой проблемы, класс-реализация должен просто определить этот метод.
Когда у обоих интерфейсов объявлены методы с одинаковой сигнатурой, но разными возвращаемыми типами – всё зависит от того, какие именно эти типы.
Переопределение метода (override) еще с Java 5 ковариантно относительно возвращаемого типа. То есть, в наследнике тип результата метода может быть наследником: super метод возвращает Number, @Override метод возвращает Integer.
Если типы не связаны отношением наследования, например String и Long – такой класс невозможно реализовать.
Для примитивов никакой ковариантности возвращаемого типа нет. Даже если типы совместимы относительно присваивания: int→long, int→Integer. В любом из таких случаев будет ошибка о несовместимости возвращаемых типов, для примитивов они должны совпадать в точности.
Если различие в части throws, методы объявлены выбрасывающими разные типы исключений. Правила здесь те же, что для возвращаемых типов – работает ковариантность. Отличие лишь в том, что исключений примитивных типов не бывает, а даже для не являющихся родителем и наследником исключений всегда есть вариант, удовлетворяющий обоим – отсутствие выбрасываемых исключений вообще.
👍17
Java-разработчик в HR Tech
Москва, Санкт-Петербург, гибрид/офис
Middle-Senior
Подразделение HR Tech разрабатывает, поддерживает и развивает внутренние сервисы Яндекса. Мы отвечаем за десятки важных систем, необходимых для нормального функционирования компании. Наши пользователи — все сотрудники Яндекса: можно общаться с ними напрямую и получать актуальный фидбек. Мы активно растём и развиваемся вместе с компанией, задач перед нами стоит с каждым годом все больше, они становятся амбициознее и сложнее.
Команда компенсаций и бюджетирования отвечает за материальную (и не только) мотивацию сотрудников и занимается учётом того, сколько всё это стоит. У нас два десятка микросервисов, сформировавшийся стек технологий и опытные специалисты. Присоединяйтесь, если пишете на Java и/или Kotlin!
Что нужно делать:
- разрабатывать новые сервисы, развивать и поддерживать существующие;
- иногда рефакторить;
- проводить ревью кода и обсуждать технические решения;
- делиться знаниями и опытом, не стесняться просить поделиться коллег;
- участвовать в жизни команды :)
Мы ждем, что вы:
- владеете Java (и/или Kotlin), понимаете, как работает экосистема Java;
- работали со Spring Framework или очень хотите с ним познакомиться и готовы оперативно изучить;
- владеете или готовы изучить SQL;
- ассоциируете слова «Docker» и «контейнер» не только с портом;
- технически грамотны;
- пишете эффективный и понятный код;
- способны и готовы объяснять свои решения, договариваться с коллегами;
- самостоятельны;
- готовы работать в команде;
- увлечены тем, что делаете, и хотите влиять на результат общей работы, чтобы повысить уровень счастья пользователей, а не просто закрывать задачи.
Откликнуться: https://clck.ru/35VCbv
Москва, Санкт-Петербург, гибрид/офис
Middle-Senior
Подразделение HR Tech разрабатывает, поддерживает и развивает внутренние сервисы Яндекса. Мы отвечаем за десятки важных систем, необходимых для нормального функционирования компании. Наши пользователи — все сотрудники Яндекса: можно общаться с ними напрямую и получать актуальный фидбек. Мы активно растём и развиваемся вместе с компанией, задач перед нами стоит с каждым годом все больше, они становятся амбициознее и сложнее.
Команда компенсаций и бюджетирования отвечает за материальную (и не только) мотивацию сотрудников и занимается учётом того, сколько всё это стоит. У нас два десятка микросервисов, сформировавшийся стек технологий и опытные специалисты. Присоединяйтесь, если пишете на Java и/или Kotlin!
Что нужно делать:
- разрабатывать новые сервисы, развивать и поддерживать существующие;
- иногда рефакторить;
- проводить ревью кода и обсуждать технические решения;
- делиться знаниями и опытом, не стесняться просить поделиться коллег;
- участвовать в жизни команды :)
Мы ждем, что вы:
- владеете Java (и/или Kotlin), понимаете, как работает экосистема Java;
- работали со Spring Framework или очень хотите с ним познакомиться и готовы оперативно изучить;
- владеете или готовы изучить SQL;
- ассоциируете слова «Docker» и «контейнер» не только с портом;
- технически грамотны;
- пишете эффективный и понятный код;
- способны и готовы объяснять свои решения, договариваться с коллегами;
- самостоятельны;
- готовы работать в команде;
- увлечены тем, что делаете, и хотите влиять на результат общей работы, чтобы повысить уровень счастья пользователей, а не просто закрывать задачи.
Откликнуться: https://clck.ru/35VCbv
yandex.ru
Вакансия «Java-разработчик в HR Tech» в Яндексе — работа в компании Яндекс для IT-специалистов
Работа в компании Яндекс для специалиста «Java-разработчик в HR Tech» с уровнем квалификации от «Специалист» до «Старший» — Высокая заработная плата и социальные гарантии в IT-компании России
👍6
Как изменить значение приватного финального поля?
Стоит сразу сказать, это очень плохая практика. Такое изменение грубо нарушает принципы сокрытия данных, и потенциально ломает инвариантность состояния объекта.
Для этого трюка необходимо прибегнуть к использованию Reflection API.
Сначала получим дескриптор поля – экземпляр класса Field. У объекта метакласса Class<X> интересующего нас класса вызовем метод getDeclaredField(). Просто getField() не сработает, потому что он работает только с публичными полями. Параметром передается строка с именем поля.
Полученного экземпляра Field уже достаточно для доступа к изменяемым приватным полям. Перед обращением требуется сделать его доступным, вызвав setAccessible(true).
Сам доступ осуществляется методами get*() и set*(). Так как Field представляет дескриптор поля класса, без привязки к конкретному экземпляру класса, экземпляр передается параметром в методы доступа. Для статического поля передается null.
Чтобы побороть неизменяемость финального поля, нужно снять его модификатор final. Все модификаторы поля хранятся в поле modifiers дескриптора. То есть, нужно также с помощью рефлекшена сделать доступным и обновить поле уже объекта Field.
Поле modifiers хранит модификаторы в виде битовой маски. Для изменения придется прибегнуть к битовым операторам.
Полный код установки значения 42 в поле myField объекта myObject выглядит так:
Стоит сразу сказать, это очень плохая практика. Такое изменение грубо нарушает принципы сокрытия данных, и потенциально ломает инвариантность состояния объекта.
Для этого трюка необходимо прибегнуть к использованию Reflection API.
Сначала получим дескриптор поля – экземпляр класса Field. У объекта метакласса Class<X> интересующего нас класса вызовем метод getDeclaredField(). Просто getField() не сработает, потому что он работает только с публичными полями. Параметром передается строка с именем поля.
Полученного экземпляра Field уже достаточно для доступа к изменяемым приватным полям. Перед обращением требуется сделать его доступным, вызвав setAccessible(true).
Сам доступ осуществляется методами get*() и set*(). Так как Field представляет дескриптор поля класса, без привязки к конкретному экземпляру класса, экземпляр передается параметром в методы доступа. Для статического поля передается null.
Чтобы побороть неизменяемость финального поля, нужно снять его модификатор final. Все модификаторы поля хранятся в поле modifiers дескриптора. То есть, нужно также с помощью рефлекшена сделать доступным и обновить поле уже объекта Field.
Поле modifiers хранит модификаторы в виде битовой маски. Для изменения придется прибегнуть к битовым операторам.
Полный код установки значения 42 в поле myField объекта myObject выглядит так:
Field field = myObject.class.getDeclaredField( "myField" );
field.setAccessible( true );
Field modifiersField = Field.class.getDeclaredField( "modifiers" );
modifiersField.setAccessible( true );
modifiersField.setInt( field, field.getModifiers() & ~Modifier.FINAL );
field.setInt(myObject, 42);👍22🔥3❤1