Инструкции по Использованию Интерфейса Java — Являются методами get и методами set в интерфейсе плохо?

Я не понимаю, почему интерфейс не может определять геттеры и сеттеры. Например, List.size () фактически является геттером. Интерфейс должен определять поведение, а не реализацию , хотя - он не может сказать, как вы обработаете состояние, но он может настаивать на том, чтобы вы могли его получить и установить.

Интерфейсы коллекций, например, связаны с состоянием, но разные коллекции могут хранить это состояние радикально по-разному.

РЕДАКТИРОВАТЬ: комментарии предполагают, что геттеры и сеттеры подразумевают, что для резервного хранилища используется простое поле. Я категорически не согласен с этим утверждением. На мой взгляд, подразумевается, что «достаточно дешево» получить / установить значение, но не то, что оно хранится как поле с тривиальной реализацией.

РЕДАКТИРОВАТЬ: Как отмечено в комментариях, это явно указано в Спецификация JavaBeans раздел 7.1:

Таким образом, даже когда автор сценария набирает в чем-то вроде b.Label = foo все еще есть вызов метода в целевой объект для установки свойства, и целевой объект имеет полный программное управление.

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

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

Например, рассмотрим компонент с

getWidth()
getHeight()
getSize()

. Считаете ли вы, что здесь есть три переменных? Разве не было бы разумным иметь:

private int width;
private int height;

public int getWidth() {
    return width;
}

public int getHeight() {
    return height;
}

public Size getSize() {
    return new Size(width, height); // Assuming an immutable Size type
}

Или (желательно IMO):

private Size size;

public int getWidth() {
    return size.getWidth();
}

public int getHeight() {
    return size.getHeight();
}

public Size getSize() {
    return size;
}

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

Я вообще не думаю, что у bean-компонента должен быть интерфейс поверх него. Javabean - это интерфейс в более общем смысле. Интерфейс определяет внешний контракт чего-то более сложного. Внешний контракт javabean'а и его внутреннее представление идентичны.

Я бы не сказал, что у вас не должно быть геттеров в интерфейсе. Имеет смысл иметь интерфейс ReadableDataThingie, который реализуется DataThingieBean.

В геттерах / сеттерах по сути нет ничего плохого. Однако:

1. Я стараюсь сделать свои объекты неизменяемыми (в первую очередь) по отношению к содержащимся в них полям. Почему ? Большинство вещей я создаю на этапе строительства. Если я хочу что-то изменить позже, я снимаю эти ограничения. Так что мои интерфейсы будут содержать геттеры, но не сеттеры (есть и другие преимущества - в частности, многопоточность).
2. Я хочу, чтобы мои объекты делали что-то за меня , а не наоборот. Поэтому, когда один из моих объектов получает несколько геттеров, я начинаю спрашивать, должен ли этот объект иметь больше функциональных возможностей вместо того, чтобы предоставлять все свои данные для чего-то другого, с чем можно работать. См. этот ответ для более подробной информации.

Это все рекомендации, примечание.

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

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

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

Для дальнейшего чтения: Практическое признание дизайна API архитектора Java Framework (Ярослав Тулач, 2008, Apress).

Я использовал такие интерфейсы, например, у нас были классы с полями beginDate, endDate. Эти поля были во многих классах, и у меня был один вариант использования, когда мне нужно было получить эти даты для разных объектов, поэтому я извлек интерфейс и был очень счастлив :)

Обычно, если ответ на вопрос «Нужно ли мне знать значение [state, property, AnyThignAMaGit], чтобы работать с его экземпляром?» тогда да ... аксессоры принадлежат интерфейсу.

List.size () от Джона выше - прекрасный пример геттера, который должен быть определен в интерфейсе

Геттеры используются для запроса состояния объекта - что вы действительно можете избегайте при разработке интерфейса. Прочтите http://www.pragprog.com/articles/tell-dont-ask

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

Для начала, по крайней мере, с Java и исключая объявления Exception, вы не можете определить полное поведение без состояния. В Java интерфейсы не определяют поведение. Они не могут. Они определяют типы; обещания реализации набора сигнатур функций, возможно, с некоторыми исключениями пост-условий. Но это все. Поведение и состояние определяются классами, реализующими эти интерфейсы.

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

Учитывая это, нет ничего плохого - синтаксически и семантически - в наличии сеттеров и геттеров в интерфейсах.

Если ваше приложение хорошо смоделировано и проблема требует наличия интерфейса, определяющего сеттеры и геттеры, почему бы и нет. Например, взгляните на интерфейс ServletResponse.

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

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

Надеюсь, это поможет.