Интерфейс как маркировки плохая практика в Java OO?
Отрывок, Вы отправили просто образец для показа то, что Вы пытаетесь сделать?
причина, которую я спрашиваю, состоит в том, что Вы назвали метод increment, но Вы, кажется, используете это, чтобы установить значение текстовой метки, вместо того, чтобы увеличить значение.
, При попытке сделать, что-то более сложное - такое как устанавливание целочисленного значения и наличие маркировки отображает это значение, Вы могли рассмотреть использование привязки. например,
Вы объявляете свойство count и Ваш increment, действие устанавливает это значение к тому, что, и затем в IB, Вы связываете текст маркировки со значением count. Пока Вы следуете за Кодированием значения ключа (KVC) с count, Вы не должны писать код для обновления дисплея маркировки. И с точки зрения дизайна у Вас есть более свободная связь.
3 ответа
Интерфейсы в качестве маркеров в значительной степени заменены механизмом аннотации в Java 5 или новее. Они позволяют добавлять произвольные метаданные. Если ваши интерфейсы пусты и служат только как маркеры класса, тогда вам следует использовать аннотации.
Хотя аннотации могут предоставить альтернативу тому, что выполняют интерфейсы маркеров, они доступны только в Java и плохо интегрируются с IDE: я также использую интерфейсы маркеров для тегирования связанных концепций в моем проекте, и затем я могу использовать браузер иерархии типов, чтобы найти все элементы (я думаю, что это будет в конечном итоге поддерживаться основными IDE для аннотаций).
Что касается статьи, которую вы упомянули, я не вижу смысла утверждать, что если Класс синтаксически / структурно «выполняет» интерфейс, этот интерфейс может / должен автоматически применяться к классу («Любой класс может объявить его [RandomAccess] как интерфейс ...»). На мой взгляд, это обратное мышление.
Я бы сказал, что места, где такой интерфейс маркера используется в операторе ʻinstanceof ', используют обратную логику,
Аннотации не обязательно то, что вам нужно. Разметка интерфейсов - это способ встраивания свойства типа в сам тип. Например, если вы собираетесь начать писать такой код:
@interface ContainableTag{}
@ContainableTag public class Foo {}
// ... elsewhere...
/**
* Adds obj as a child element.
* @throws IllegalArgumentException if obj is not tagged with
* the ContainableTag annotation.
*/
public void addElement(Object obj){
if (!obj.getClass().isAnnotationPresent(ContainableTag.class))
throw new IllegalArgumentException("obj is not a ContainableTag");
// add the containable tag as an element
}
Тогда подумайте, действительно ли вам кажется, что это выглядит не лучше:
interface ContainableTag {}
public class Foo implements ContainableTag {}
// ... elsewhere...
public void addElement(ContainableTag ct){
// add the containable tag as an element
}
Конечно, интерфейс тегов не предоставляет никакой информации о том, какое поведение тип сам предоставляет, но делает позволяет другим типам применять это свойство, не связанное с поведением. Конечно, я бы избежал множества досадных ошибок, если бы ObjectOutputStream имел метод writeObject (Serializable) , а не writeObject (Object) .
Изменить: