Почему атрибуты на Java могут быть общедоступными?

Ответ 1

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

Например, я часто выставляю публичные статические конечные элементы данных как общедоступные (например, константы). Я не считаю это вредным.

Я укажу, что эта ситуация верна и на других языках, кроме Java: С++, С# и т.д.

Языки не всегда должны защищать нас от самих себя.

В примере Оли, какой вред я пишу так?

public class Point {
   public final int x;
   public final int y;

   public Point(int p, int q) {
      this.x = p;
      this.y = q;
   } 
}

Он неизменен и безопасен по потоку. Члены данных могут быть общедоступными, но вы не можете навредить им.

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

Так расслабься. Это не так уж плохо.

Ответ 2

Для гибкости. Было бы огромной болью, если бы я не смог написать:

class Point {
    public int x;
    public int y;
}

Существует огромное преимущество, чтобы скрыть это за геттерами и сеттерами.

Ответ 3

Поскольку жесткая "инкапсуляция данных" не является единственной парадигмой, а также обязательной особенностью ориентации объекта.

И, более того, если у вас есть атрибут данных, который имеет общедоступный метод setter и общедоступный метод getter, а методы ничего не делают, кроме как фактически устанавливают/получают атрибут, то какой смысл держать его в тайне?

Ответ 4

Не все классы следуют парадигме инкапсуляции (например, классы factory). Для меня это повышает гибкость. И, во всяком случае, ответственность за программист, а не за язык, зависит от сферы действия.

Ответ 5

Обсуждение хорошей стороны публичных переменных... Нравится это...:)

Существует много причин использовать переменные public. Пусть они поочередно проверяют:

Производительность

Хотя это редкость, будут ситуации, в которых это имеет значение. В некоторых случаях следует избегать накладных расходов на вызов метода.

Константы

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

public static final String ACCEPTABLE_PUBLIC = "Acceptable public variable";

Другие случаи

В некоторых случаях, когда public не имеет значения или нет геттера и сеттера, нет необходимости. Хороший пример с Point уже написан как ответ.

Ответ 6

Объектно-ориентированный дизайн не требует инкапсуляции. Это лучшая практика в таких языках, как Java, которая имеет гораздо больше общего с языковым дизайном, чем OO.

Лучше всего всегда инкапсулировать в Java по одной простой причине. Если вы не инкапсулируете, вы не можете впоследствии инкапсулировать, не меняя подписи объекта. Например, если у вашего сотрудника есть имя, и вы делаете его общедоступным, это employee.name. Если позже вы захотите инкапсулировать его, вы получите employee.getName() и employee.setName(). это, конечно же, нарушит любой код, используя класс Employee. Таким образом, в Java лучше всего инкапсулировать все, чтобы вам не приходилось менять подпись объекта.

Некоторые другие языки OO (ActionScript3, С# и т.д.) поддерживают истинные свойства, где добавление getter/setter не влияет на подпись. В этом случае, если у вас есть геттер или сеттер, он заменяет общедоступное свойство той же самой подписью, поэтому вы можете легко переключаться туда и обратно без нарушения кода. На этих языках практика всегда инкапсулирования больше не нужна.

Ответ 7

Java - это ветвь из языков синтаксиса стиля C. Эти языки поддерживали struct, которые были фиксированными псевдонимами сглаживания для блока памяти, который обычно определялся как "один элемент". Другими словами, структуры данных были реализованы с помощью struct s.

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

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

Ответ 8

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

Связанный пример может быть одним из заданий @Oli Charlesworth

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

Я действительно не могу придумать вескую причину не использовать геттеры и сеттеры за пределами лености. Эффективная Java, которая широко считается одной из лучших java-книг, говорит, что всегда использует геттеры и сеттеры.    Если вам не нужно слышать о том, почему вы всегда должны использовать геттеры и сеттеры, пропустите этот абзац. Я не согласен с примером ответа 1-го числа Точки как времени, чтобы не использовать геттеры и сеттеры. С этим связано несколько проблем. Что делать, если вам нужно изменить тип номера. Например, однажды, когда я экспериментировал с графикой, я обнаружил, что часто меняю мнение о погоде. Я хочу сохранить местоположение в форме Java или непосредственно как int, как он демонстрировал. Если бы я не использовал геттеры и сеттеры, и я изменил это, мне пришлось бы изменить весь код, который использовал местоположение. Однако, если бы я этого не сделал, я мог бы просто изменить получателя и сеттера.

Getters и seters - это боль в Java. В Scala вы можете создавать публичные элементы данных, а затем геттеры и/или сеттеры позже без изменения API. Это дает вам лучшее из обоих миров! Возможно, Java установит это на один день.