2

Если мне нужно только переустанавливать значения поля, а доступ на чтение к нему не нужен, стоит ли мне предоставить для этого поля только сеттер? Или все таки лучше создать еще и геттер "на будущее"?

Александр Елизаров
  • 2,788
  • 2
  • 18
  • 36
  • Ответ на данный вопрос зависит от предпочтений конкретного разработчика. Поэтому точный ответ вы не получите. – u_mulder Dec 12 '15 at 19:45
  • @u_mulder Например, точным будет тот ответ, который опишет подводные камни связанные с этим, недостатки и преимущества. Считайте что это вопрос с Programmers.SE – Kromster Dec 12 '15 at 20:08
  • Аналогичный вопрос: http://stackoverflow.com/questions/12455849/interface-setter-without-a-getter – Kromster Dec 12 '15 at 20:12
  • Мне кажется недостаток создания геттера на будущее - в том что мы плодим ненужные методы. Ведь никто не помешает нам его создать в тот момент когда понадобится доступ на чтение к этому полю. Преимуществ не вижу совсем никаких. Подводных камней в том что бы не создавать геттер "на будущее" тоже. Поправьте пожалуйста, если ошибаюсь. – Александр Елизаров Dec 12 '15 at 20:13
  • @АлександрЕлизаров скажу одну слово - "инкапсуляция". – Suvitruf - Andrei Apanasik Dec 12 '15 at 20:24
  • @Suvitruf, не понимаю( а чем непредоставление геттера нарушает инкапсуляцию? Я же не собираюсь делать поле публичным или открывать какую-либо другую реализацию – Александр Елизаров Dec 12 '15 at 20:28

1 Answers1

2

Для начала, геттер публичный или нет?

Если публичный, то стоит определиться, должно ли быть свойство доступно на чтение. Если нет, то и суда нет, не надо делать геттер.

Если private/protected, то это вопрос удобства.

Скажем, есть у нас:

public class MyClass{
   private MyField myField;

   public void setMyField(MyField value){
      myField = value;
   }
}

Если у нас есть класс наследник, который должен иметь доступ к полю, то мы либо делаем свойство protected, либо делаем protected геттер на него.

В чём плюсы геттера? Если в базовом классе решите поменять название поля, к примеру, то вам после этого надо будет поменять только геттер. Если же нет геттера, то везде, где у вас обращение к this.myField придётся вносить изменения.

В общем, единственная причина не делать геттер - это когда вам необходимо, чтобы к полю нельзя было обратиться. Но мне видится это странным: сеттер без геттера. Если вам необходимо лишь устанавливать значение, но запретить доступ на чтение, то лучше это делать с помощью билдера или передавать в конструкторе.

Да и если рассуждать логически, то тот, кто вызвал сеттер, уже и так знает значение, поэтому в надобности геттера нет вовсе.

Suvitruf - Andrei Apanasik
  • 32,302
  • да, мне было интересно именно про публичный геттер. А речь идет о поле, которое является ArrayList-ом. Я не хочу делать для него геттер, потому что через этот геттер можно же добавить к нему элемент, например. А в конструкторе передавать и убирать сеттер тоже не вариант - получается что каждый раз, когда нужно изменить всего одно поле, придется создавать новый объект. А билдер - это вы паттерн имеете в виду? – Александр Елизаров Dec 12 '15 at 20:51
  • @АлександрЕлизаров да, паттерн Билдер, когда объект конструируется лишь один раз вначале. – Suvitruf - Andrei Apanasik Dec 12 '15 at 20:53
  • @Suvirtuf, спасибо за направление, буду разбираться – Александр Елизаров Dec 12 '15 at 20:54