Что такое маркерный интерфейс

Что проверяют

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

Как отвечать

Маркерный интерфейс это интерфейс без методов и полей. Он ничего не добавляет к поведению, но добавляет типу факт, который проверяется через instanceof или читается рефлексией.

Примеры в стандартной библиотеке: Serializable разрешает сериализацию, без него поток объектов бросит NotSerializableException; Cloneable снимает запрет на Object.clone, который иначе бросит CloneNotSupportedException; RandomAccess сообщает алгоритмам, что доступ по индексу дёшев, и они выбирают разные стратегии для списка на массиве и для связного списка.

Схема применения:

interface Auditable {}

void save(Object entity) {
    if (entity instanceof Auditable) {
        writeAuditRecord(entity);
    }
    repository.persist(entity);
}

Сильная часть ответа это сравнение с аннотацией. Аннотация гибче: у неё есть параметры, её вешают на метод и поле, она не засоряет иерархию типов. Маркерный интерфейс даёт то, чего аннотация не даёт никогда: тип. Параметр метода объявляется маркером, и компилятор сам не пропустит чужой объект, то есть ошибка не доживает до рантайма.

Где спотыкаются

Проверяют instanceof на переменной, тип которой уже реализует маркер. Условие всегда истинно и смысла не несёт: маркер нужен там, где на вход приходит объект неизвестного класса.

Говорят, что Cloneable даёт метод clone. Не даёт: он лишь переключает поведение унаследованного метода, а публичный clone с правильной сигнатурой и с копированием вложенных объектов пишется руками.

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