Как вы принимаете решение определить переменную "private"?

Ответ 1

Ограничивая доступ к "другому коду" (возможно, написанному/поддерживаемому другими), вы в дальнейшем можете изменить его в будущем, не беспокоясь о нарушении какого-либо другого кода, который опирается на него.

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

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

Ответ 2

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

Ответ 3

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

Даже для частных классов, это своего рода большая сделка.

Итак, когда вы когда-нибудь измените область действия переменной на private в будущем? Для этого есть много возможных причин. Самое простое, что ваш класс, возможно, должен будет что-то делать каждый раз, когда изменяется значение переменных (например, регистрируйте изменение или обновляйте другие переменные). Или позже вы решите, что переменная вообще не нужна, и что значение, запрашиваемое пользователем, должно вычисляться "на лету" вместо этого.

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

Потому что, как правило, вы никогда не можете предвидеть такие будущие изменения, стало лучше использовать переменную no public. Каждая переменная должна быть private (или, по крайней мере, внутренней).

(Есть одно исключение: в некоторых случаях переменные final можно безопасно сделать public. Например, константы, подобные перечислению, часто реализуются как public final переменные в библиотеках Java, потому что они никогда не изменятся, и нет управление доступом требуется, поскольку они доступны только для чтения).

Ответ 4

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

Так как общее правило private должно быть по умолчанию

Ответ 5

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

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

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

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

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

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

Ответ 6

Если вы что-то достигли, указав переменную private, не можете ли вы добиться того же путем определения любого другого модификатора доступа, определенного в java?

Да. Это правда. Любой private можно изменить на public (или protected и т.д.), И программа будет компилироваться и запускаться так же, как и раньше.

Модификаторы доступа доступны для удобства программистов и помогают ему правильно определить интерфейс класса. Посмотрите статью в википедии об инкапсуляции.

Ответ 7

член закрыт в случаях:

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

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

Ответ 8

Основной темой классов является инкапсуляция данных и поведения и скрытие внутренней реализации, а также внешняя визуализация чистого, простого и полезного API.

Можно рассмотреть две разные вещи: публичный контракт (API) и частные данные.

• Частные поля: это ваши личные данные, которые вы не хотите открывать извне из-за: безопасности и целостности.

• Частные методы: ваши служебные функции делают код более читабельным и поддерживаемым.

• Публичные методы: контракт (интерфейс, API), который вы публикуете другим людям. Это делает ваши классы полезными.

• Публичные поля: не используйте это. Он предоставляет только часть ваших внутренних данных. Для простых классов может быть хорошо, а для сложных классов с взаимозависимыми полями это большой нет-нет. Для раскрытия функциональности вы должны использовать общедоступные методы (пункт 3.).

Ответ 9

Многие из этих комментариев относятся к внутреннему/вложенному классу, методам и конструкторам.

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

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