Почему переменные экземпляра в Java всегда закрыты?

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

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

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

Если phone был закрытым:

Рассмотрим этот случай:

class Address {
  private String phone;

  public void setPhone(String phone) {
    this.phone = phone;
  }
}

//access:
Address a = new Address();
a.setPhone("001-555-12345");

Если бы мы начали с такого класса, а позже потребовалось бы выполнять проверки phoneNumber (например, некоторую минимальную длину, только цифры и т. д.), вам просто нужно было бы изменить установщик:

class Address {
  private String phone;

  public void setPhone(String phone) {
    if( !isValid( phone) ) { //the checks are performed in the isValid(...) method
     throw new IllegalArgumentException("please set a valid phone number");
    }

    this.phone = phone;
  }
}

//access:
Address a = new Address();
a.setPhone("001-555-12345"); //access is the same

Если phone был общедоступным:

Кто-то мог установить phone вот так, и вы ничего не могли с этим поделать:

Address a = new Address();
a.phone="001-555-12345";

Если теперь вы хотите принудительно выполнить проверки проверки, вам придется сделать это приватным, и тот, кто написал вышеуказанные строки, должен будет изменить вторую строку на это:

a.setPhone("001-555-12345");

Таким образом, вы не могли просто добавить проверки, не нарушая остальной код (он больше не будет компилироваться).

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

Они не должны обязаны быть частными, но должны быть ими. Поле — это деталь реализации, поэтому его следует держать в секрете. Если вы хотите разрешить пользователям извлекать или устанавливать его значение, вы используете для этого свойства (методы получения и установки) — это позволяет вам делать это безопасно (например, проверять ввод), а также позволяет изменять детали реализации (например, чтобы делегировать некоторые значения другим объектам и т. д.) без потери обратной совместимости.

Во-первых, неверно, что все переменные экземпляра являются частными. Некоторые из них защищены, что по-прежнему сохраняет инкапсуляцию.

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

Например, если у вас есть два логических поля, и класс может нормально работать только в 3 случаях: [false, false], [false, true] и [true, false]. Если вы сделаете поля общедоступными, другой объект может установить [true, true], не зная внутренних ограничений, и следующий метод, вызванный для исходного объекта, вызовет неожиданные результаты.

Делать переменные экземпляра общедоступными или закрытыми — это компромисс дизайна, на который разработчик идет при объявлении классов. Делая переменные экземпляра общедоступными, вы раскрываете детали реализации класса, тем самым обеспечивая более высокую эффективность и лаконичность выражений за счет возможного снижения усилий по обслуживанию в будущем. Скрыв детали внутренней реализации класса, вы можете изменить реализацию класса в будущем, не нарушая код, использующий этот класс.

Технический документ Oracle

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

Я видел пример в (как мне кажется) Clean Code, который очень хорошо это иллюстрирует. Если я правильно помню, это был тип комплексного числа (как в a+bi); во всяком случае, что-то очень похожее, у меня нет книги под рукой. Он предоставил методы для получения значения реальной и мнимой частей, а также метод для установки значения экземпляра. Большим преимуществом этого является то, что он позволяет полностью заменить реализацию без нарушения каких-либо потребителей кода. Например, комплексные числа можно хранить в одной из двух форм: в виде координат на комплексной плоскости (a+bi) или в полярной форме (φ и |z|). Сохранение внутреннего формата хранения в качестве детали реализации позволяет вам переключаться туда и обратно, по-прежнему отображая число в обеих формах, что позволяет пользователю класса выбирать то, что более удобно для операции, которую они в настоящее время выполняют.

В других ситуациях у вас может быть набор связанных полей, например, поле x должно иметь определенные свойства, если поле y попадает в заданный диапазон. В упрощенном примере x должно быть в диапазоне от y до y+z для числовых значений и некоторого произвольного значения z. Предоставляя средства доступа и мутаторы, вы можете установить эту связь между двумя значениями; если вы выставите переменные экземпляра напрямую, инвариант немедленно развалится, поскольку вы не можете гарантировать, что кто-то не установит одну, а другую, или не установит их так, что инвариант больше не будет выполняться.

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

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

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

ОБНОВЛЕНИЕ: пример, приведенный в ссылке в вопросе, является прекрасным примером этой вырожденной инкапсуляции. Я понимаю, что автор пытается предоставить простой пример, но при этом не может передать никаких реальных преимуществ инкапсуляции (по крайней мере, не в коде примера).

1. Потому что если вы измените структуру класса (удалив поля и т.д.); это вызовет ошибки. Но если у вас есть метод getX(), вы можете вычислить нужное значение там (если поле было удалено).

2. У вас проблема в том, что класс не знает, изменилось ли что-то, и не может гарантировать целостность.

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

Уровень по умолчанию позволяет избежать беспорядка в вашем собственном коде и не позволяет клиентам вашего кода устанавливать недопустимые значения.