(Предостережение: я не программист на Java, я программист на Perl. У Perl нет формальной защиты, поэтому, возможно, поэтому я так хорошо понимаю проблему :))
Частный
Как вы думаете, только класс, в котором он объявлен, может видеть его.
Пакет Приват
Его может видеть и использовать только тот пакет, в котором он был объявлен. Это значение по умолчанию в Java (что некоторые считают ошибкой).
защищенный
Пакет Private + может просматриваться подклассами или членами пакета.
общественного
Каждый может это увидеть.
Видимо за пределами кода, который я контролирую. (Хотя это не синтаксис Java, это важно для этого обсуждения).
C ++ определяет дополнительный уровень, называемый «друг», и чем меньше вы знаете об этом, тем лучше.
Когда вы должны использовать что? Вся идея заключается в инкапсуляции, чтобы скрыть информацию. Как можно больше вы хотите скрыть детали того, как что-то делается от ваших пользователей. Почему? Потому что тогда вы можете изменить их позже и не нарушать чей-либо код. Это позволяет оптимизировать, реорганизовывать, перепроектировать и исправлять ошибки, не беспокоясь о том, что кто-то использовал этот код, который вы только что пересмотрели.
Таким образом, эмпирическое правило состоит в том, чтобы делать вещи только такими видимыми, какими они должны быть. Начните с частного и добавьте больше видимости по мере необходимости. Обнародуйте только то, что абсолютно необходимо знать пользователю, каждая деталь, которую вы публикуете, ограничивает вашу способность перепроектировать систему.
Если вы хотите, чтобы пользователи могли настраивать поведение, а не публиковать внутренние данные, чтобы они могли их переопределить, часто лучше вставить эти внутренности в объект и сделать этот интерфейс общедоступным. Таким образом, они могут просто подключить новый объект. Например, если вы писали проигрыватель компакт-дисков и хотели, чтобы бит "go find info об этом компакт-диске" был настраиваемым, вместо того, чтобы делать эти методы общедоступными, вы поместили бы всю эту функциональность в свой собственный объект и сделали бы доступным только объект-получатель / установщик объекта , Таким образом, скупость в разоблачении своих внутренностей способствует хорошей композиции и разделению проблем.
Лично я придерживаюсь только «частного» и «общественного». У многих ОО-языков это есть. «Защищенный» может быть удобен, но это действительно обман. Как только интерфейс становится более приватным, он становится вне вашего контроля, и вам нужно искать код других людей, чтобы найти применение.
Вот тут-то и возникает идея «опубликованного». Изменение интерфейса (его рефакторинг) требует, чтобы вы нашли весь код, который его использует, и изменили его тоже. Если интерфейс является частным, то нет проблем. Если он защищен, вы должны найти все свои подклассы. Если это общедоступно, вы должны найти весь код, который использует ваш код. Иногда это возможно, например, если вы работаете над корпоративным кодом, предназначенным только для внутреннего использования, не имеет значения, является ли интерфейс общедоступным. Вы можете получить весь код из корпоративного хранилища. Но если интерфейс «опубликован», если есть код, использующий его вне вашего контроля, то вы попадаете в ловушку. Вы должны поддерживать этот интерфейс или рисковать нарушением кода. Даже защищенные интерфейсы можно считать опубликованными (поэтому я не
Многие языки считают иерархическую природу публичного / защищенного / частного слишком ограничивающей и не соответствующей действительности. Для этого есть концепция класса черты , но это еще одно шоу.
private
скрывается от других классов в пакете.public
подвергает классам вне пакета.protected
версияpublic
ограничена только подклассами.