Это находится в антишаблоне, чтобы всегда использовать, добираются и методы установки получить доступ к собственным членским полям класса? [дубликат]

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

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

Если вы пишете свой код для доступа к переменным без геттера, подумайте о том, чтобы сделать функцию геттера "финальной". Таким образом, никто не будет пытаться переопределить ваш код и рвать на себе волосы, недоумевая, почему он не работает. (Обратите внимание, что прокси Spring и Hibernate могут сделать это плохой идеей.)

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

Другое дело, что другим клиентам / программистам может потребоваться использовать ваш класс так, как вам не нравится. Я еще не думал, например, о том, чтобы извлечь класс «Соглашение» из базы данных. В этом случае, когда они переопределяют ваш класс, вы сделали безболезненным для них (или, возможно, для вас в будущем) изменение способа получения этих данных.

Так что, если вы не абсолютно уверены, что существует только один способ доступа это поле, и что оно на 100% прямое, это '

Мне кажется, что некоторые люди интерпретируют этот вопрос как о геттерах и сеттерах, которые используются извне; Моя интерпретация вопроса Паблоджима заключалась в том, что речь идет об их использовании в классе, в отличие от класса, напрямую обращающегося к своим полям. (Которые частные.)

В этом свете я с Jherico и patros; используйте прямой доступ из класса, если нет причин не делать этого.

Сохранение уровня абстракции - это хорошо в Java.

Проблема в том, что весь код, который напрямую обращается к вашим переменным-членам, не обращая внимания на класс, не находится под контролем вашего класса.

Таким образом, в тот момент, когда вы решите отредактировать свой класс таким образом, чтобы один член, используемый в подразделении в качестве примера, никогда не был равен 0, вы должны быть в состоянии гарантировать, что это значение изменяется только таким образом, чтобы гарантировать это . Итак, вы должны добавить сеттер для этого метода и изменить член на частный. Но теперь вам нужно изменить весь код, который обращается к члену без установщика.
Если вы знаете, что изменяете значение извне класса, и только затем предоставляете сеттер, если вы не знаете, сделать переменную частной и если вам понадобится доступ позже, возможно, предоставьте геттер или сеттер.

Он получает Anti- Шаблон, если в других объектах есть определенные методы, которые всегда используют get для члена, затем выполняет некоторые вычисления, а затем использует get. Это показывает, что либо член должен быть в другом классе, либо метод должен быть в этом классе.

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

Сейчас я работаю над тем, что заставляет меня в пользу геттеров: теперь мы перемещаем часть наших свойств в «мешок свойств», что означает, что вы не можете просто ссылаться на переменную . Таким образом, помимо изменения получателя, нам нужно изменить все места, которые ссылаются на эту переменную. Об этом следует помнить.

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

Если вы обернули поле в публичный get, то есть причина, по которой вы это сделали. Возможно, в этом методе есть логика для отложенной загрузки поля или обеспечения контрольного журнала. Какой бы ни была причина использования метода, вашему классу, скорее всего, понадобится и эта логика.

Чтобы он был анти-шаблоном, он должен быть явно вредным. Я не понимаю, как может быть вред в определении геттеров и сеттеров. В лучшем случае это пустая трата времени (и набор текста), что делает его бессмысленным, но не антипаттерном.

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

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

class EXAMPLE
feature
  variable: INTEGER
  variable_function: INTEGER
    do
      result := 4
    end
  variable_two: INTEGER assign variable_assign
  variable_assign (in: INTEGER)
    do
      variable_two := in
    end  
end

feature
test
local
  test: EXAMPLE
  value: INTEGER
do
  create test
  value := test.variable  -- Valid
  value := test.variable_function  -- Valid and same even though it's a function
  test.variable := value -- Invalid
  test.variable_two := value -- Valid, an explicit setter is defined
end

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

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

Однако все зависит от того, как вы используете свои геттеры и сеттеры.

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