В чем смысл интерфейса маркеров в java и почему мы не можем обойтись без них?

Вы четко понимаете, что делают интерфейсы маркеров. Ты сам так сказал!

Так зачем они нам все еще нужны?

В каком-то смысле они нам не нужны. Все, что вы можете выразить с помощью интерфейсов маркеров, вы можете выразить с помощью аннотаций. Нет сомнений в том, что аннотации - лучший способ решить проблему.

Основная причина, по которой у нас (все еще) есть интерфейсы маркеров, - История:

• Аннотации Java были добавлены в язык Java в Java 5.0. До этого лучшим доступным решением были маркерные интерфейсы.

• Удаление интерфейсов маркеров из класса нарушает бинарную совместимость.

• Существует небольшое количество интерфейсов маркеров Java SE, которые предшествовали Java 5.0 и широко используются в пользовательском коде. На ум приходят два Serializable и Cloneable.

Нравится нам это или нет, но в Java есть маркерные интерфейсы, и это вряд ли изменится.

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

Ну да. С точки зрения 2019 года это правда.

С точки зрения 1997 года, когда Java была новой, а до C # оставалось 5 лет, единственными распространенными (-ish) языками с чем-то вроде аннотаций были версии LISP.

Теперь я почти уверен, что разработчики библиотеки классов Java еще в эпоху Java 1.0 знали, что интерфейсы маркеров были ошибочной идеей. Но у них не было альтернативы. Это было использование интерфейсов-маркеров или откладывание разработки и реализации некоторых хороших фундаментальных API-интерфейсов Java на 5 или более лет.

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

Вам не нужно реализовывать Serializable для сериализации или Cloneable для клонирования. Суть этих интерфейсов в том, что Java имеет встроенные механизмы для клонирования и сериализации, и вам нужно реализовать эти интерфейсы только в том случае, если вы хотите использовать эти встроенные механизмы.

Таким образом, просто реализовав Serializable, вы автоматически сможете использовать этот класс с ObjectInputStream и ObjectOutputStream без какого-либо дополнительного кода.

Клонируемый, с другой стороны, я считаю практически бесполезным. Обычно вы просто реализуете Cloneable, переопределяете Object.clone и делаете его общедоступным, и вы мгновенно получаете клонирование. Но говорят, что он сломан, и вам лучше просто написать собственную логику клонирования, например, с помощью конструктора копирования.

Точки, которые любой класс может реализовать без добавления каких-либо дополнительных методов / полей / накладных расходов

Вы просто помечаете класс, и он готов к использованию / сериализации.

Даже после Java 5.0, где были введены аннотации,

Еще есть аннотации маркеров в виде @Configuration

Аннотация @Configuration используется для конфигурации на основе аннотаций Spring. @Configuration - это аннотация маркера, которая указывает, что класс объявляет один или несколько методов @Bean и может обрабатываться контейнером Spring для создания определений bean-компонентов и запросов на обслуживание для этих bean-компонентов во время выполнения.

Я могу ответить на ваш частичный вопрос - В чем смысл интерфейса маркера в java?

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

Так в чем же ключевая разница?

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

Например, добавим ограничение, что из базы данных можно удалить только тип Shape:

public interface Shape {
    double getArea();
    double getCircumference();
}

В этом случае интерфейс нашего маркера, назовем его DeletableShape, будет выглядеть следующим образом:

public interface DeletableShape extends Shape {
}

Затем наш класс будет реализовывать интерфейс маркера:

public class Rectangle implements DeletableShape {
    // implementation details
}

Следовательно, все реализации DeletableShape также являются реализациями Shape. Очевидно, мы не можем сделать это с помощью аннотаций.

Однако каждое дизайнерское решение имеет компромиссы, и полиморфизм может использоваться как контраргумент против интерфейсов маркеров. В нашем примере каждый класс, расширяющий Rectangle, автоматически реализует DeletableShape.

Это может не дать точного ответа на ваш запрос. Но может частично помочь вам.

Источник: baeldung.com