В Java разница между пакетом private, public, protected и private

В Java существуют ли четкие правила, когда использовать каждый из модификаторов доступа, а именно, по умолчанию (закрытый пакет), public , protected и private , делая class и interface и занимаясь наследованием?

    Официальный учебник может быть вам полезен.

                 │ Класс │ Пакет │ Подclass │ Подclass │ Мир
                 │ │ │ (одинаковый pkg) │ (diff pkg) │ 
     ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
     public │ + │ + │ + │ + │ +     
     ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
     защищенный │ + │ + │ + │ + │         
     ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
     нет модификатора │ + │ + │ + │ │    
     ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
     частный │ + │ │ │ │    
    
     +: ansible
     пусто: недоступно
    

    (Caveat: Я не программист на Java, я программист Perl. Perl не имеет формальных защит, возможно, поэтому я так хорошо понимаю проблему :))

    Частный

    Как вы думаете, это может увидеть только class, в котором он объявлен.

    Частный пакет

    Может отображаться и использоваться только пакетом, в котором он был объявлен. Это значение по умолчанию в Java (которое некоторые считают ошибкой).

    защищенный

    Пакет Private + можно увидеть подclassами или членами пакета.

    общественного

    Все это видят.

    опубликованный

    Видимый вне кода, который я контролирую. (Хотя это не синтаксис Java, это важно для этого обсуждения).

    C ++ определяет дополнительный уровень, называемый «friend», и чем меньше вы знаете, тем лучше.

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

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

    Если вы хотите, чтобы пользователи могли настраивать поведение, а не открывать внутренности, чтобы они могли переопределить их, часто лучше перетащить эти кишки в объект и сделать этот интерфейс общедоступным. Таким образом, они могут просто подключить новый объект. Например, если вы пишете проигрыватель компакт-дисков и хотите, чтобы бит «идти найти информацию об этом компакт-диске» настраивался, а не публиковать эти методы, вы включили бы все эти функции в свой собственный объект и сделали бы свой объект getter / setter общедоступным , Таким образом, скупость о том, чтобы разоблачить ваши кишки, поощряет хороший состав и разделение проблем

    Лично я придерживаюсь только «частных» и «публичных». У многих языков OO есть это. «Защищенный» может пригодиться, но это действительно чит. Когда интерфейс более чем частный, он находится вне вашего контроля, и вам нужно искать в коде других людей, чтобы найти пользу.

    Здесь возникает идея «опубликования». Изменение интерфейса (рефакторинг) требует, чтобы вы нашли весь код, который его использует, и также измените его. Если интерфейс частный, то проблем нет. Если он защищен, вам нужно найти все ваши подclassы. Если это общедоступно, вам нужно найти весь код, который использует ваш код. Иногда это возможно, например, если вы работаете с корпоративным кодом, который используется только для внутреннего использования, не имеет значения, открыт ли интерфейс. Вы можете извлечь весь код из корпоративного репозитория. Но если интерфейс «опубликован», если есть код, использующий его вне вашего контроля, тогда вы будете закрыты. Вы должны поддерживать этот интерфейс или код нарушения риска. Даже защищенные интерфейсы можно считать опубликованными (поэтому я не беспокоюсь о защите).

    Многие языки находят иерархическую природу public / protected / private слишком ограничивающей и не соответствующей действительности. С этой целью существует концепция classа признаков , но это еще одно шоу.

    Вот лучшая версия таблицы. (Будущее доказательство с колонкой для модhive.)

    Модификаторы Java-доступа

    Пояснения

    • Частный член доступен только в том же classе, который был объявлен.

    • Член без модификатора доступа доступен только в classах одного и того же пакета.

    • Защищенный член доступен во всех classах одного и того же пакета и внутри подclassов в других пакетах.

    • Публичный член доступен для всех classов (если он не находится в модуле , который не экспортирует пакет, в котором он объявлен).


    Какой модификатор выбрать?

    Модификаторы доступа – это инструмент, который поможет вам предотвратить случайное нарушение инкапсуляции (*) . Спросите себя, хотите ли вы, чтобы член был чем-то внутренним для classа, пакета, иерархии classов или вообще не был внутренним, и соответственно выберите уровень доступа.

    Примеры:

    • long internalCounter запрос должен быть закрытым, поскольку он изменен и детализация реализации.
    • Класс, который должен быть создан только в фабричном classе (в том же пакете), должен иметь конструктор с ограниченным пакетом, поскольку его нельзя будет вызывать непосредственно извне пакета.
    • Внутренний метод void beforeRender() который void beforeRender() непосредственно перед рендерингом и используется как подclass в подclassах, должен быть защищен.
    • void saveGame(File dst) который вызывается из кода GUI, должен быть общедоступным.

    (*) Что такое инкапсуляция?

      | highest precedence <---------> lowest precedence *———————————————+———————————————+———————————+———————————————+——————— \ xCanBeSeenBy | this | any class | this subclass | any \__________ | class | in same | in another | class \ | nonsubbed | package | package | Modifier of x \ | | | | ————————————————*———————————————+———————————+———————————————+——————— public | ✔ | ✔ | ✔ | ✔ ————————————————+———————————————+———————————+———————————————+——————— protected | ✔ | ✔ | ✔ | ✘ ————————————————+———————————————+———————————+———————————————+——————— package-private | | | | (no modifier) | ✔ | ✔ | ✘ | ✘ ————————————————+———————————————+———————————+———————————————+——————— private | ✔ | ✘ | ✘ | ✘ 

    Простое правило. Начните с объявления всех частных. И затем прогресс в отношении общественности по мере возникновения потребностей, и дизайн ее оправдывает.

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

    Как правило, я стараюсь избегать переопределения реализации метода путем подclassа; слишком легко испортить логику. Объявите абстрактные защищенные методы, если вы намерены переопределить его.

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

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

    Доступ по умолчанию (указанный отсутствием ключевого слова) также называется package-private . Исключение: в интерфейсе никакой модификатор не означает открытый доступ; модификаторы, отличные от общедоступных, запрещены. Константы континуума всегда открыты.

    Резюме

    Разрешен ли доступ к члену с этим спецификатором доступа?

    • Член private : только если член определен в том же classе, что и вызывающий код.
    • Член закрывается пакетом: только если вызывающий код находится внутри пакета, входящего в состав участника.
    • Участник protected : тот же пакет, или если член определен в суперclassе classа, содержащего вызывающий код.
    • Участник public : Да.

    Какие спецификаторы доступа применяются к

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

    Для classов в верхней области допускаются только public и пакетные. Вероятно, этот выбор дизайна обусловлен тем, что protected и private будут избыточными на уровне пакета (наследование пакетов отсутствует).

    Все возможности доступа доступны для членов classа (конструкторы, методы и статические функции-члены, вложенные classы).

    Связанный: Доступность classа Java

    порядок

    Спецификаторы доступа могут быть строго упорядочены

    public> protected> package-private> private

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

    Заметки

    • Методам classа разрешается доступ к закрытым членам других объектов того же classа. Точнее, метод classа C может обращаться к частным членам C на объектах любого подclassа C. Java не поддерживает ограничение доступа экземпляром только по classу. (Сравните с Scala, который поддерживает его с помощью private[this] .)
    • Вам нужен доступ к конструктору для создания объекта. Таким образом, если все конструкторы являются частными, class может быть создан только кодом, живущим внутри classа (обычно статические фабричные методы или инициализаторы статической переменной). Аналогично для конструкторов private-private или protected.
      • Только наличие частных конструкторов также означает, что class не может быть подclassифицирован извне, поскольку Java требует, чтобы конструкторы подclassа неявно или явно вызывали конструктор суперclassа. (Однако он может содержать вложенный class, который подclassифицирует его.)

    Внутренние classы

    Вы также должны учитывать вложенные области, такие как внутренние classы. Примером сложности является то, что внутренние classы имеют члены, которые сами могут использовать модификаторы доступа. Таким образом, вы можете иметь частный внутренний class с открытым членом; может ли доступ к члену? (См. Ниже.) Общее правило заключается в том, чтобы взглянуть на область действия и подумать рекурсивно, чтобы узнать, можете ли вы получить доступ к каждому уровню.

    Однако это довольно сложно, и для получения полной информации обратитесь к Спецификации Java Language . (Да, в прошлом были compiler errors.)

    Чтобы понять, как они взаимодействуют, рассмотрим этот пример. Возможно «утечка» частных внутренних classов; это обычно предупреждение:

     class Test { public static void main(final String ... args) { System.out.println(Example.leakPrivateClass()); // OK Example.leakPrivateClass().secretMethod(); // error } } class Example { private static class NestedClass { public void secretMethod() { System.out.println("Hello"); } } public static NestedClass leakPrivateClass() { return new NestedClass(); } } 

    Выход компилятора:

     Test.java:4: secretMethod() in Example.NestedClass is defined in an inaccessible class or interface Example.leakPrivateClass().secretMethod(); // error ^ 1 error 

    Некоторые связанные вопросы:

    • Java – Доступность метода внутри пакета-частного classа?

    Как правило большого пальца:

    • private : class.
    • default (или package-private ): область пакета.
    • protected : package scope + child (например, пакет, но мы можем подclassифицировать его из разных пакетов). Защищенный модификатор всегда сохраняет отношения «родитель-ребенок».
    • общественность : везде.

    В результате, если мы разделим права доступа на три права:

    • (D) direct (вызов из метода внутри одного classа).
    • (R) (вызов метода с использованием ссылки на class или синтаксис «точка»).
    • (I) nheritance (через подclassификацию).

    то у нас есть эта простая таблица:

     +—-———————————————+————————————+———————————+ | | Same | Different | | | Package | Packages | +—————————————————+————————————+———————————+ | private | D | | +—————————————————+————————————+———————————+ | package-private | | | | (no modifier) | DRI | | +—————————————————+————————————+———————————+ | protected | DRI | I | +—————————————————+————————————+———————————+ | public | DRI | RI | +—————————————————+————————————+———————————+ 

    В очень короткие сроки

    • public : доступная извне.
    • protected : доступ к classам одного и того же пакета и подclassам, находящимся в любом пакете.
    • default (не указан модификатор): доступен classами одного и того же пакета.
    • private : доступно только в одном classе.

    Самый непонятый модификатор доступа в Java protected . Мы знаем, что он похож на модификатор по умолчанию с одним исключением, в котором подclassы могут его видеть. Но как? Вот пример, который, надеюсь, прояснит путаницу:

    • Предположим, что у нас есть 2 classа; Father и Son , каждый в своем собственном пакете:

       package fatherpackage; public class Father { } ------------------------------------------- package sonpackage; public class Son extends Father { } 
    • Давайте добавим защищенный метод foo() к Father .

       package fatherpackage; public class Father { protected void foo(){} } 
    • Метод foo() можно вызвать в четырех контекстах:

      1. Внутри classа, который находится в том же пакете, где определен foo() ( fatherpackage ):

         package fatherpackage; public class SomeClass { public void someMethod(Father f, Son s) { f.foo(); s.foo(); } } 
      2. Внутри подclassа, в текущем экземпляре с помощью this или super :

         package sonpackage; public class Son extends Father { public void sonMethod() { this.foo(); super.foo(); } } 
      3. На ссылке, тип которой является одним и тем же classом:

         package fatherpackage; public class Father { public void fatherMethod(Father f) { f.foo(); // valid even if foo() is private } } ------------------------------------------- package sonpackage; public class Son extends Father { public void sonMethod(Son s) { s.foo(); } } 
      4. На ссылке, тип которой является родительским classом, и находится внутри пакета, где определен foo() ( fatherpackage ) [Это может быть включено внутри контекста no. 1]:

         package fatherpackage; public class Son extends Father { public void sonMethod(Father f) { f.foo(); } } 
    • Следующие ситуации недействительны.

      1. В ссылке, тип которой является родительским classом, и она находится вне пакета, где определяется foo() ( fatherpackage ):

         package sonpackage; public class Son extends Father { public void sonMethod(Father f) { f.foo(); // compilation error } } 
      2. Неподclass в пакете подclassа (подclass наследует защищенные члены от его родителя и делает их частными для не-подclassов):

         package sonpackage; public class SomeClass { public void someMethod(Son s) throws Exception { s.foo(); // compilation error } } 

    Частный

    • Методы, переменные и конструкторы

    Методы, переменные и конструкторы, объявленные частными, могут быть доступны только в объявленном classе.

    • Класс и интерфейс

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

    Заметка

    Переменные, объявленные как private, могут быть доступны вне classа, если в classе присутствуют общедоступные методы getter. Переменные, методы и конструкторы, объявленные защищенными в суперclassе, могут быть доступны только подclassам другого пакета или любого classа в пакете classа защищенных членов.


    защищенный

    • Класс и интерфейс

    Модификатор защищенного доступа не может применяться к classу и интерфейсам.

    Методы, поля могут быть объявлены защищенными, однако методы и поля в интерфейсе не могут быть объявлены защищенными.

    Заметка

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


    общественного

    Доступ к classу, методу, конструктору, интерфейсу и т. Д. Может быть доступен из любого другого classа.

    Поэтому поля, методы, блоки, объявленные внутри открытого classа, могут быть доступны из любого classа, принадлежащего к Java Universe.

    • Различные пакеты

    Однако, если открытый class, к которому мы пытаемся получить доступ, находится в другом пакете, тогда публичный class по-прежнему необходимо импортировать.

    Из-за наследования classов все общедоступные методы и переменные classа наследуются подclassами.


    По умолчанию – Нет ключевого слова:

    Модификатор доступа по умолчанию означает, что мы явно не объявляем модификатор доступа для classа, поля, метода и т. Д.

    • В пределах тех же пакетов

    Переменная или метод, объявленный без модификатора управления доступом, доступен для любого другого classа в одном пакете. Поля в интерфейсе неявно являются публичными статическими, а методы в интерфейсе по умолчанию являются общедоступными.

    Заметка

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

    Ответы на вопросы

    • Переопределение статических методов в java

    Ссылки ссылки

    http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html http://www.tutorialspoint.com/java/java_access_modifiers.htm

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

    Частный : ограниченный доступ только к classу

    По умолчанию (без модификатора) : ограниченный доступ к classу и пакету

    Защищенный : ограниченный доступ к classу, пакету и подclassам (как внутри, так и снаружи пакета)

    Публикация : доступ к classу, пакету (все) и подclassам … Короче, везде.

    Модификаторы доступа в Java.

    Модификаторы доступа Java используются для обеспечения контроля доступа на Java.

    1. По умолчанию:

    Доступно только для classов только в одном пакете.

    Например,

     // Saved in file A.java package pack; class A{ void msg(){System.out.println("Hello");} } // Saved in file B.java package mypack; import pack.*; class B{ public static void main(String args[]){ A obj = new A(); // Compile Time Error obj.msg(); // Compile Time Error } } 

    Этот доступ более ограничен, чем общеansible и защищенный, но менее ограниченный, чем частный.

    2. Общественные

    Доступ к ним возможен из любого места. (Глобальный доступ)

    Например,

     // Saved in file A.java package pack; public class A{ public void msg(){System.out.println("Hello");} } // Saved in file B.java package mypack; import pack.*; class B{ public static void main(String args[]){ A obj = new A(); obj.msg(); } } 

    Вывод: Привет

    3. Частный

    Доступно только внутри одного classа.

    Если вы попытаетесь получить доступ к закрытым членам одного classа в другом, это приведет к ошибке компиляции. Например,

     class A{ private int data = 40; private void msg(){System.out.println("Hello java");} } public class Simple{ public static void main(String args[]){ A obj = new A(); System.out.println(obj.data); // Compile Time Error obj.msg(); // Compile Time Error } } 

    4. Защищенный

    Доступно только для classов в одном пакете и подclassах

    Например,

     // Saved in file A.java package pack; public class A{ protected void msg(){System.out.println("Hello");} } // Saved in file B.java package mypack; import pack.*; class B extends A{ public static void main(String args[]){ B obj = new B(); obj.msg(); } } 

    Вывод: Привет

    Введите описание изображения здесь

    Модификаторы доступа предназначены для ограничения доступа на нескольких уровнях.

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

    Чтобы получить доступ, если вы находитесь в одном пакете, вы можете получить доступ напрямую, но если вы находитесь в другом пакете, вы можете создать объект classа.

    По умолчанию: он доступен в одном пакете из любого classа пакета.

    Для доступа вы можете создать объект classа. Но вы не можете получить доступ к этой переменной за пределами пакета.

    Защищено: вы можете обращаться к переменным в том же пакете, а также подclassе в любом другом пакете. поэтому в основном это значение по умолчанию + Наследуемое поведение.

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

    Частный: это может быть доступ в том же classе.

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

    Видимый для пакета. По умолчанию. Модификаторы не нужны.

    Видимый только для classа ( закрытый ).

    Видно миру ( общественность ).

    Видимый для пакета и всех подclassов ( защищенных ).

    Переменные и методы могут быть объявлены без каких-либо модификаторов, которые вызываются. Примеры по умолчанию:

     String name = "john"; public int age(){ return age; } 

    Модификатор частного доступа – частный:

    Методы, переменные и конструкторы, объявленные частными, могут быть доступны только в объявленном classе. Модификатор частного доступа является самым ограничивающим уровнем доступа. Класс и интерфейсы не могут быть частными.

    Переменные, объявленные как private, могут быть доступны вне classа, если в classе присутствуют общедоступные методы getter.

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

    Примеры:

     Public class Details{ private String name; public void setName(String n){ this.name = n; } public String getName(){ return this.name; } } 

    Модификатор общедоступного доступа – общеansible:

    Доступ к classу, методу, конструктору, интерфейсу и т. Д. Может быть доступен из любого другого classа. Поэтому поля, методы, блоки, объявленные внутри открытого classа, могут быть доступны из любого classа, принадлежащего к юниверситету Java.

    Однако, если открытый class, к которому мы пытаемся получить доступ, находится в другом пакете, тогда публичный class по-прежнему необходимо импортировать.

    Because of class inheritance, all public methods and variables of a class are inherited by its subclasses.

    Пример:

     public void cal(){ } 

    Protected access modifier – protected:

    Variables, methods and constructors which are declared protected in a superclass can be accessed only by the subclasses in another package or any class within the package of the protected members’ class.

    The protected access modifier cannot be applied to class and interfaces. Methods, fields can be declared protected, however methods and fields in a interface cannot be declared protected.

    Protected access gives the subclass a chance to use the helper method or variable, while preventing a nonrelated class from trying to use it.

     class Van{ protected boolean speed(){ } } class Car{ boolean speed(){ } } 

    I just want to address a detail that is extremely commonly got wrong, including by most of the answers on this page. “Default” access (when no access modifier is present) is not always the same as package-private . It depends on what the thing is.

    • Non-member types (that is, classes, enums, interfaces, and annotation types not declared inside another type) are package-private by default. ( JLS §6.6.1 )

    • Class members and constructors are package-private by default. ( JLS §6.6.1 )

    • Enum constructors are private by default . (Indeed, enum contructors must be private, and it is an error to try to make them public or protected). Enum constants are public, and do not allow any access specifier. Other members of enums are package-private by default. ( JLS §8.9 )

    • All members of interfaces and annotation types are public by default . (Indeed, members of interfaces and annotation types must be public, and it is an error to try to make them private or protected.) ( JLS §9.3 to 9.5 )

    This page writes well about the protected & default access modifier

    …. Protected: Protected access modifier is the a little tricky and you can say is a superset of the default access modifier. Protected members are same as the default members as far as the access in the same package is concerned. The difference is that, the protected members are also accessible to the subclasses of the class in which the member is declared which are outside the package in which the parent class is present.

    But these protected members are “accessible outside the package only through inheritance“. ie you can access a protected member of a class in its subclass present in some other package directly as if the member is present in the subclass itself. But that protected member will not be accessible in the subclass outside the package by using parent class’s reference. ….

    • public – accessible from anywhere in the application.

    • default – accessible from package.

    • protected – accessible from package and sub-classes in other package. as well

    • private – accessible from its class only.

    David’s answer provides the meaning of each access modifier. As for when to use each, I’d suggest making public all classes and the methods of each class that are meant for external use (its API), and everything else private.

    Over time you’ll develop a sense for when to make some classes package-private and when to declare certain methods protected for use in subclasses.

    • Visible to the package. the default . No modifiers are needed.
    • Visible to the class only; private .
    • Visible to the world; public .
    • Visible to the package and all subclasses; protected .

    So let’s talk about Access Control and Inheritance The following rules for inherited methods are,

    • Methods declared public in a superclass also must be public in all subclasses.
    • Methods declared protected in a superclass must either be protected or public in subclasses; they cannot be private.
    • Methods declared without access control (no modifier was used) can be declared more private in subclasses.
    • Methods declared private are not inherited at all, so there is no rule for them.

    Note: This is just a supplement for the accepted answer.

    This is related to Java Access Modifiers .

    From Java Access Modifiers :

    A Java access modifier specifies which classes can access a given class and its fields, constructors and methods. Access modifiers can be specified separately for a class, its constructors, fields and methods. Java access modifiers are also sometimes referred to in daily speech as Java access specifiers, but the correct name is Java access modifiers. Classes, fields, constructors and methods can have one of four different Java access modifiers:

    • Элемент списка
    • private
    • default (package)
    • защищенный
    • общественности

    From Controlling Access to Members of a Class tutorials:

    Access level modifiers determine whether other classes can use a particular field or invoke a particular method. There are two levels of access control:

    • At the top level—public, or package-private (no explicit modifier).
    • At the member level—public, private, protected, or package-private (no explicit modifier).

    A class may be declared with the modifier public, in which case that class is visible to all classes everywhere. If a class has no modifier (the default, also known as package-private), it is visible only within its own package

    The following table shows the access to members permitted by each modifier.

     ╔═════════════╦═══════╦═════════╦══════════╦═══════╗ ║ Modifier ║ Class ║ Package ║ Subclass ║ World ║ ╠═════════════╬═══════╬═════════╬══════════╬═══════╣ ║ public ║ Y ║ Y ║ Y ║ Y ║ ║ protected ║ Y ║ Y ║ Y ║ N ║ ║ no modifier ║ Y ║ Y ║ N ║ N ║ ║ private ║ Y ║ N ║ N ║ N ║ ╚═════════════╩═══════╩═════════╩══════════╩═══════╝ 

    The first data column indicates whether the class itself has access to the member defined by the access level. As you can see, a class always has access to its own members. The second column indicates whether classes in the same package as the class (regardless of their parentage) have access to the member. The third column indicates whether subclasses of the class declared outside this package have access to the member. The fourth column indicates whether all classes have access to the member.

    Access levels affect you in two ways. First, when you use classes that come from another source, such as the classes in the Java platform, access levels determine which members of those classes your own classes can use. Second, when you write a class, you need to decide what access level every member variable and every method in your class should have.

    Public Protected Default and private are access modifiers.

    They are meant for encapsulation, or hiding and showing contents of the class.

    1. Class can be public or default
    2. Class members can be public, protected, default or private.

    Private is not accessible outside the class Default is accessible only in the package. Protected in package as well as any class which extends it. Public is open for all.

    Normally, member variables are defined private, but member methods are public.

    Often times I’ve realized that remembering the basic concepts of any language can made possible by creating real-world analogies. Here is my analogy for understanding access modifiers in Java:

    Let’s assume that you’re a student at a university and you have a friend who’s coming to visit you over the weekend. Suppose there exists a big statue of the university’s founder in the middle of the campus.

    • When you bring him to the campus, the first thing that you and your friend sees is this statue. This means that anyone who walks in the campus can look at the statue without the university’s permission. This makes the statue as PUBLIC .

    • Next, you want to take your friend to your dorm, but for that you need to register him as a visitor. This means that he gets an access pass (which is the same as yours) to get into various buildings on campus. This would make his access card as PROTECTED .

    • Your friend wants to login to the campus WiFi but doesn’t have the any credentials to do so. The only way he can get online is if you share your login with him. (Remember, every student who goes to the university also possesses these login credentials). This would make your login credentials as NO MODIFIER .

    • Finally, your friend wants to read your progress report for the semester which is posted on the website. However, every student has their own personal login to access this section of the campus website. This would make these credentials as PRIVATE .

    Надеюсь это поможет!

    When you are thinking of access modifiers just think of it in this way (applies to both variables and methods ):

    public –> accessible from every where
    private –> accessible only within the same class where it is declared

    Now the confusion arises when it comes to default and protected

    default –> No access modifier keyword is present. This means it is available strictly within the package of the class. Nowhere outside that package it can be accessed.

    protected –> Slightly less stricter than default and apart from the same package classes it can be accessed by sub classes outside the package it is declared.

    It is all about encapsulation (or as Joe Phillips stated, least knowledge ).

    Start with the most restrictive (private) and see if you need less restrictive modifiers later on.

    We all use method and member modifiers like private, public, … but one thing too few developers do is use packages to organize code logically.

    For example: You may put sensitive security methods in a ‘security’ package. Then put a public class which accesses some of the security related code in this package but keep other security classes package private . Thus other developers will only be able to use the publicly available class from outside of this package (unless they change the modifier). This is not a security feature, but will guide usage.

     Outside world -> Package (SecurityEntryClass ---> Package private classes) 

    Another thing is that classes which depend a lot on each other may end up in the same package and could eventually be refactored or merged if the dependency is too strong.

    If on the contrary you set everything as public it will not be clear what should or should not be accessed, which may lead to writing a lot of javadoc (which does not enforce anything via the compiler…).

    Interesting Posts

    Неожиданное сохранение данных

    Как отдать приоритет привилегированной теме при блокировке мьютекса?

    Загрузка сайтов обновлений плагинов Eclipse для автономной установки

    Как суммировать все значения в столбце в Jaspersoft iReport Designer?

    Простой встроенный способ шифрования и дешифрования файла на Mac через командную строку?

    Использование службы для запуска фона и создания уведомлений

    Является ли мой MAC-адрес общедоступным при просмотре Интернета?

    Как округлить время до ближайшего квартального часа в java?

    не может преобразовать ‘std :: basic_string ‘ в ‘const char *’ для аргумента ‘1’ в ‘int system (const char *)’

    Как вычислить площадь 2-го многоугольника?

    Решить перекрестное streamовое исключение в WinForms

    jQuery UI DatePicker – Изменить формат даты

    OpenCV CV :: Mat и Eigen :: Matrix

    Выведите R-команду через что-то вроде try ()

    Как запустить Eclipse с использованием новой версии 1.7 для JDK для Mac?

    Давайте будем гением компьютера.