Рекомендации по использованию интерфейса Java - Являются ли геттеры и сеттеры в интерфейсе плохими?
===================================================================================================

Что люди думают о лучших рекомендациях для интерфейса? Что должно и не должно входить в интерфейс?

Я слышал, как люди говорят, что, как правило, интерфейс должен определять только поведение, а не состояние. Значит ли это, что интерфейсshouldn't contain getters and setters?

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

Я думаю, что есть два типа интерфейсов, заявленных в целом:

a **service description**. This might be something like `CalculationService`. I don't think that methods `getX` should be in this sort of interface, and certainly not `setX`. They quite clearly imply implementation detail, which is not the job of this type of interface.
a **data model** - exists solely to abstract out the implementation of data objects in the system. These might be used to aid in testing or just because some people as old as me remember the days when (for example) using a persistence framework tied you down to having a particular superclasss (i.e. you would choose to implement an interface in case you switched your persistence layer). I think that having JavaBean methods in this type of interface is entirely reasonable.

Note: the collections classes probably fit in to type #2



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

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

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

РЕДАКТИРОВАТЬ: Как отмечается в комментариях, это четко указано в[Спецификация JavaBeans](http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html) раздел 7.1:

Thus even when a script writer types
 in something such as `b.Label = foo`
 there is still a method call into the
 target object to set the property, and
 the target object has full
 programmatic control.

So properties need not just be simple
 data fields, they can actually be
 computed values. Updates may have
 various programmatic side effects. For
 example, changing a bean’s background
 color property might also cause the
 bean to be repainted with the new
 color."

Если предполагаемое значениеwere правда, мы можем точно так же выставлять свойства как поля напрямую. К счастью, это подразумеваетdoesn't держись: геттеры и сеттеры совершенно в пределах своих прав для вычисления вещей.

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

Верите ли вы, что существует три переменных? Разве не разумно иметь:

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

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



 Практические API Признания в дизайне Java Framework Architect (Ярослав Тулач, 2008, Apress).



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



Это касается всей темы «Getter / Setters» - злая тема, которая неоднократно обсуждается на этом сайте и в других местах.

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



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

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



I've heard people say that, as a
 general rule, an interface must only
 define behavior and not state. Does
 this mean that an interface shouldn't
 contain getters and setters?

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

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

**With that into consideration, there is nothing wrong - syntactically and semantically - with having setters and getters in interfaces.** 

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

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

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

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



Нет ничего плохого в добытчиках / сеттерах. Тем не мение:

I tend to make my objects immutable (in the first instance) with respect to the fields they contain. Why ? I instantiate most things during the construction phase. If I want to change something later then I relax those restrictions. So my interfaces will tend to contain getters, but not setters (there are other benefits - particularly threading).
I want my objects to do things for me, not the other way around. So when one of my objects acquires a number of getters, I start to ask whether that object should have more functionality in it, rather than exposing all its data for something else to work with. See [this answer](https://stackoverflow.com/questions/1062656/object-dosomething-vs-dosomethingwithobject/1062715#1062715) for more detail.

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



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



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