In Java unterscheiden sich die Pakete privat, öffentlich, geschützt und privat

Gibt es in Java klare Regeln für die Verwendung der einzelnen Zugriffsmodifizierer, nämlich die Standardwerte (Paket privat), public , protected und private , während die class und die interface und die inheritance behandelt wird?

    Das offizielle Tutorial könnte für Sie von Nutzen sein.

                 │ class │ Paket │ Unterklasse │ Unterklasse │ Welt
                 Same │ │ (gleiches Paket) │ (diff pkg) │ 
     ─────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────────
     öffentlich │ + │ + │ + │ + │ +     
     ─────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────────
     geschützt │ + │ + │ + │ + │         
     ─────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────────
     kein Modifikator │ + │ + │ + │ │    
     ─────────────────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────────
     privat │ + │ │ │ │    
    
     +: zugänglich
     leer: nicht erreichbar
    

    (Achtung: Ich bin kein Java-Programmierer, ich bin ein Perl-Programmierer. Perl hat keinen formellen Schutz, weshalb ich das Problem vielleicht so gut verstehe :))

    Privatgelände

    Wie Sie denken, kann nur die class, in der es deklariert ist, es sehen.

    Paket privat

    Kann nur von dem Paket, in dem es deklariert wurde, gesehen und verwendet werden. Dies ist der Standard in Java (was einige als Fehler sehen).

    Geschützt

    Das Paket Private + kann von Unterklassen oder Paketmitgliedern gesehen werden.

    Öffentlichkeit

    Jeder kann es sehen.

    Veröffentlicht

    Sichtbar außerhalb des Codes, den ich kontrolliere. (Dies ist zwar nicht die Java-Syntax, aber wichtig für diese Diskussion).

    C ++ definiert eine zusätzliche Stufe namens “Freund” und je weniger Sie darüber wissen, desto besser.

    Wann solltest du was benutzen? Die ganze Idee ist Verkapselung, um Informationen zu verbergen. So viel wie möglich möchten Sie das Detail verbergen, wie etwas von Ihren Benutzern ausgeführt wird. Warum? Denn dann kannst du sie später ändern und niemandes Code kaputt machen. Dadurch können Sie Bugs optimieren, umgestalten, neu gestalten und beheben, ohne befürchten zu müssen, dass jemand den überholten Code verwendet.

    Faustregel ist also, Dinge nur so sichtbar zu machen, wie sie sein müssen. Beginnen Sie mit privat und fügen Sie nur bei Bedarf mehr Sichtbarkeit hinzu. Veröffentlichen Sie nur das, was für den Benutzer absolut notwendig ist, jedes Detail, das Sie öffentlich machen, verkrampft Ihre Fähigkeit, das System neu zu gestalten.

    Wenn Sie möchten, dass Benutzer Verhaltensweisen anpassen können, anstatt Interna öffentlich zu machen, damit sie diese überschreiben können, ist es oft eine bessere Idee, diese Eingeweide in ein Objekt zu schieben und diese Schnittstelle öffentlich zu machen. Auf diese Weise können sie einfach ein neues Objekt einstecken. Wenn Sie beispielsweise einen CD-Player schreiben und das Bit “Informationen zu dieser CD suchen” möchten, anstatt diese Methoden öffentlich zu machen, würden Sie all diese functionen in ein eigenes Objekt einfügen und Ihr Objekt Getter / Setter öffentlich machen . Auf diese Art und Weise geizig zu sein, um Ihre Eingeweide freizulegen, fördert eine gute Zusammensetzung und Trennung von Sorgen

    Persönlich bleibe ich bei “privat” und “öffentlich”. Viele OO-Sprachen haben das nur. “Geschützt” kann praktisch sein, aber es ist wirklich ein Betrüger. Sobald eine Schnittstelle mehr als nur privat ist, liegt sie außerhalb Ihrer Kontrolle und Sie müssen in den Code anderer Leute schauen, um Verwendungen zu finden.

    Hier kommt die Idee von “published” ins Spiel. Das Ändern einer Schnittstelle (Refactoring) erfordert, dass Sie den gesamten Code, der sie benutzt, finden und ändern können. Wenn die Schnittstelle privat ist, ist das kein Problem. Wenn es geschützt ist, musst du alle deine Unterklassen finden. Wenn es öffentlich ist, musst du den ganzen Code finden, der deinen Code benutzt. Manchmal ist dies möglich, wenn Sie beispielsweise an Unternehmenscode arbeiten, der nur für den internen Gebrauch bestimmt ist, spielt es keine Rolle, ob eine Schnittstelle öffentlich ist. Sie können den gesamten Code aus dem Unternehmens-Repository abrufen. Aber wenn eine Schnittstelle “veröffentlicht” wird, wenn Sie Code außerhalb Ihrer Kontrolle verwenden, dann werden Sie abgespritzt. Sie müssen diese Schnittstelle oder diesen Code unterstützen. Selbst geschützte Schnittstellen können als publiziert gelten (weshalb ich mich nicht mit geschützten beschäftige).

    Viele Sprachen empfinden die hierarchische Natur von öffentlich / geschützt / privat als zu einschränkend und nicht im Einklang mit der Realität. Zu diesem Zweck gibt es das Konzept einer Merkmalsklasse , aber das ist eine andere Show.

    Hier ist eine bessere Version der Tabelle. (Zukunftssicher mit einer Spalte für Module.)

    Java-Zugriffsmodifikatoren

    Erklärungen

    • Ein privates Mitglied ist nur innerhalb derselben class zugänglich, wie es deklariert ist.

    • Ein Member ohne Zugriffsmodifizierer ist nur innerhalb von classn desselben Pakets verfügbar.

    • Ein geschütztes Mitglied ist in allen classn desselben Pakets und in Unterklassen anderer Pakete verfügbar.

    • Ein öffentliches Mitglied ist für alle classn zugänglich (es sei denn, es befindet sich in einem Modul , das das Paket, in dem es deklariert ist, nicht exportiert).


    Welcher Modifikator soll gewählt werden?

    Access Modifiers ist ein Tool, mit dem Sie verhindern können, dass die Kapselung versehentlich unterbrochen wird (*) . Fragen Sie sich, ob Sie das Mitglied als internes Element der class, des Pakets, der classnhierarchie oder überhaupt nicht intern definieren möchten, und wählen Sie entsprechend die Zugriffsebene aus.

    Beispiele:

    • Ein Feld long internalCounter sollte wahrscheinlich privat sein, da es veränderbar ist und ein Implementierungsdetail.
    • Eine class, die nur in einer Factory-class (im selben Paket) instanziiert werden sollte, sollte einen Konstruktor mit eingeschränktem Paket haben, da es nicht möglich sein sollte, sie direkt von außerhalb des Pakets aufzurufen.
    • Eine interne void beforeRender() -Methode, die direkt vor dem Rendern aufgerufen wird und als Hook in Unterklassen verwendet wird, sollte geschützt werden.
    • Eine void saveGame(File dst) -Methode, die aus dem GUI-Code aufgerufen wird, sollte öffentlich sein.

    (*) Was genau ist Einkapselung?

      | 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 | ✔ | ✘ | ✘ | ✘ 

    Einfache Regel. Beginnen Sie damit, alles für privat zu erklären. Und dann Fortschritte in Richtung der Öffentlichkeit, wie die Bedürfnisse entstehen und Design es rechtfertigt.

    Wenn Sie Mitglieder exponieren, fragen Sie sich, ob Sie Repräsentationsmöglichkeiten oder Abstraktionswahlen offen legen. Das erste ist etwas, das Sie vermeiden möchten, da es zu viele Abhängigkeiten von der tatsächlichen Repräsentation und nicht von ihrem beobachtbaren Verhalten einführt.

    Als allgemeine Regel versuche ich zu vermeiden, dass Methodenimplementierungen durch Unterklassen überschrieben werden; es ist zu leicht, die Logik zu vermasseln. Deklarieren Sie abstrakte geschützte Methoden, wenn Sie beabsichtigen, sie zu überschreiben.

    Verwenden Sie außerdem beim Überschreiben die Annotation @Override, um zu verhindern, dass die Elemente beim Refactoring beschädigt werden.

    Es ist tatsächlich ein bisschen komplizierter als ein einfaches Raster zeigt. Das Grid sagt Ihnen, ob ein Zugriff zulässig ist, aber was genau einen Zugriff darstellt. Außerdem interagieren Zugriffsebenen auf komplexe Weise mit verschachtelten classn und inheritance.

    Der “Standard” -Zugriff (angegeben durch das Fehlen eines Schlüsselworts) wird auch als Paket-privat bezeichnet . Ausnahme: In einer Schnittstelle bedeutet kein Modifikator öffentlichen Zugriff; Modifikatoren außer der Öffentlichkeit sind verboten. Enum-Konstanten sind immer öffentlich.

    Zusammenfassung

    Ist ein Zugriff auf ein Mitglied mit diesem Zugriffsspezifizierer zulässig?

    • Mitglied ist private : Nur wenn Mitglied in derselben class wie der aufrufende Code definiert ist.
    • Mitglied ist Paket privat: Nur wenn sich der aufrufende Code im umschließenden Paket des Mitglieds befindet.
    • Mitglied ist protected : Gleiches Paket oder wenn Mitglied in einer Oberklasse der class definiert ist, die den aufrufenden Code enthält.
    • Mitglied ist public : Ja.

    Welche Zugriffsspezifizierer gelten für?

    Lokale Variablen und formale Parameter können keine Zugriffsspezifizierer enthalten. Da sie nach den Scoping-Regeln von Natur aus nicht zugänglich sind, sind sie effektiv privat.

    Für classn im oberen Bereich sind nur public und package-private zulässig. Diese Designauswahl ist vermutlich, weil protected und private auf der Paketebene redundant sind (es gibt keine inheritance von Paketen).

    Alle Zugriffsspezifizierer sind für classnmitglieder (Konstruktoren, Methoden und statische Elementfunktionen, verschachtelte classn) möglich.

    Verwandt: Barrierefreiheit der Java-class

    Auftrag

    Die Zugriffsspezifizierer können streng geordnet werden

    öffentlich> geschützt> paket-privat> privat

    Das bedeutet, dass die public den meisten Zugang, die private den geringsten Zugang bietet. Jede Referenz, die auf einem privaten Mitglied möglich ist, gilt auch für ein paket-privates Mitglied; Jeder Verweis auf ein privates Paket-Mitglied ist für ein geschütztes Mitglied gültig und so weiter. (Der Zugriff auf geschützte Mitglieder auf andere classn im selben Paket wurde als Fehler angesehen.)

    Anmerkungen

    • Die Methoden einer class dürfen auf private Mitglieder anderer Objekte derselben class zugreifen. Genauer gesagt kann eine Methode der class C auf Objekte jeder Unterklasse von C auf private Member von C zugreifen. Java unterstützt nicht die Einschränkung des Zugriffs nach Instanz, nur nach class. (Vergleichen Sie mit Scala, die es mit private[this] .)
    • Sie benötigen Zugriff auf einen Konstruktor, um ein Objekt zu konstruieren. Wenn also alle Konstruktoren privat sind, kann die class nur durch Code konstruiert werden, der innerhalb der class lebt (typischerweise statische Factory-Methoden oder statische Variableninitialisierungen). Ähnlich für Paket-private oder geschützte Konstruktoren.
      • Nur private Konstruktoren zu haben bedeutet auch, dass die class nicht extern unterkonsolidiert werden kann, da Java die Konstruktoren einer Unterklasse benötigt, um einen Superklassenkonstruktor implizit oder explizit aufzurufen. (Sie kann jedoch eine verschachtelte class enthalten, die sie unterklassifiziert.)

    Innere classn

    Sie müssen auch verschachtelte Bereiche berücksichtigen, z. B. innere classn. Ein Beispiel für die Komplexität ist, dass innere classn Mitglieder haben, die selbst Zugriffsmodifizierer nehmen können. So können Sie eine private innere class mit einem öffentlichen Mitglied haben; Kann auf das Mitglied zugegriffen werden? (Siehe unten.) Die allgemeine Regel besteht darin, den Bereich zu betrachten und rekursiv zu denken, um zu sehen, ob Sie auf jede Ebene zugreifen können.

    Dies ist jedoch ziemlich kompliziert und die vollständigen Einzelheiten finden Sie in der Java-Sprachspezifikation . (Ja, in der Vergangenheit gab es Compilererrors.)

    Um einen Eindruck davon zu gewinnen, wie diese interagieren, betrachten Sie dieses Beispiel. Es ist möglich, private innere classn “auszulecken”; Dies ist normalerweise eine Warnung:

     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(); } } 

    Compiler-Ausgabe:

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

    Einige verwandte Fragen:

    • Java – Methode Zugriff in Paket-private class?

    Als Faustregel gilt:

    • privat : classnumfang.
    • Standard (oder Paket-privat ): Paketbereich.
    • protected : Paketbereich + Kind (wie Paket, aber wir können es von verschiedenen Paketen ableiten). Der geschützte Modifizierer behält immer die “Eltern-Kind” -Beziehung bei.
    • öffentlich : überall.

    Wenn wir das Zugriffsrecht in drei Rechte unterteilen:

    • (D) direct (Aufruf von einer Methode innerhalb derselben class).
    • (R) reference (rufen Sie eine Methode auf, die einen Verweis auf die class oder über die “Punkt” -Syntax verwendet).
    • (I) inheritance (über Unterklassenbildung).

    dann haben wir diese einfache Tabelle:

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

    In sehr kurzer Zeit

    • public : von überall zugänglich.
    • protected : Zugänglich durch die classn des gleichen Pakets und die Unterklassen, die sich in einem beliebigen Paket befinden.
    • Standard (kein Modifikator angegeben): Zugänglich für die classn desselben Pakets.
    • private : nur in derselben class zugänglich.

    Der am meisten missverstandene Zugriffsmodifikator in Java ist protected . Wir wissen, dass es dem Standardmodifikator ähnelt, mit einer Ausnahme, in der Unterklassen es sehen können. Aber wie? Hier ist ein Beispiel, das hoffentlich die Verwirrung klärt:

    • Angenommen, wir haben 2 classn; Father und Son , jeder in seinem eigenen Paket:

       package fatherpackage; public class Father { } ------------------------------------------- package sonpackage; public class Son extends Father { } 
    • Fügen wir Father eine geschützte Methode foo() .

       package fatherpackage; public class Father { protected void foo(){} } 
    • Die Methode foo() kann in 4 Kontexten aufgerufen werden:

      1. Innerhalb einer class, die sich im selben Paket befindet, in dem foo() definiert ist ( fatherpackage ):

         package fatherpackage; public class SomeClass { public void someMethod(Father f, Son s) { f.foo(); s.foo(); } } 
      2. Innerhalb einer Unterklasse, in der aktuellen Instanz über this oder super :

         package sonpackage; public class Son extends Father { public void sonMethod() { this.foo(); super.foo(); } } 
      3. Bei einer Referenz, deren Typ dieselbe class ist:

         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. Bei einer Referenz, deren Typ die fatherpackage ist und innerhalb des Pakets liegt, in dem foo() definiert ist ( fatherpackage ) [Dies kann innerhalb der fatherpackage . 1]:

         package fatherpackage; public class Son extends Father { public void sonMethod(Father f) { f.foo(); } } 
    • Die folgenden Situationen sind nicht gültig.

      1. Bei einer Referenz, deren Typ die fatherpackage ist und außerhalb des Pakets liegt, in dem foo() definiert ist ( fatherpackage ):

         package sonpackage; public class Son extends Father { public void sonMethod(Father f) { f.foo(); // compilation error } } 
      2. Eine Nicht-Unterklasse in einem Paket einer Unterklasse (Eine Unterklasse erbt die geschützten Elemente von ihrem übergeordneten Element und macht sie für Nicht-Unterklassen privat):

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

    Privatgelände

    • Methoden, Variablen und Konstruktoren

    Auf Methoden, Variablen und Konstruktoren, die als privat deklariert sind, kann nur innerhalb der deklarierten class selbst zugegriffen werden.

    • class und Schnittstelle

    Der private Zugriffsmodifikator ist die restriktivste Zugriffsebene. class und Schnittstellen können nicht privat sein.

    Hinweis

    Auf Variablen, die als privat deklariert sind, kann außerhalb der class zugegriffen werden, wenn in der class öffentliche Getter-Methoden vorhanden sind. Auf Variablen, Methoden und Konstruktoren, die in einer Oberklasse als geschützt deklariert sind, kann nur von den Unterklassen in einem anderen Paket oder einer class innerhalb des Pakets der class der geschützten Mitglieder zugegriffen werden.


    Geschützt

    • class und Schnittstelle

    Der Modifikator für den geschützten Zugriff kann nicht auf classn und Schnittstellen angewendet werden.

    Methoden, Felder können als geschützt deklariert werden, jedoch können Methoden und Felder in einer Schnittstelle nicht als geschützt deklariert werden.

    Hinweis

    Geschützter Zugriff gibt der Unterklasse die Möglichkeit, die Hilfsmethode oder -variable zu verwenden, während sie verhindert, dass eine nicht verwandte class versucht, sie zu verwenden.


    Öffentlichkeit

    Auf eine deklarierte class class, method, constructor, interface etc. kann von jeder anderen class zugegriffen werden.

    Daher kann auf Felder, Methoden, Blöcke, die innerhalb einer öffentlichen class deklariert sind, von jeder class zugegriffen werden, die zum Java-Universum gehört.

    • Verschiedene Pakete

    Wenn die öffentliche class, auf die wir zugreifen möchten, sich jedoch in einem anderen Paket befindet, muss die öffentliche class noch importiert werden.

    Aufgrund der classnvererbung werden alle öffentlichen Methoden und Variablen einer class von ihren Unterklassen geerbt.


    Standard – Kein Schlüsselwort:

    Standardzugriffsmodifikator bedeutet, dass wir einen Zugriffsmodifizierer für eine class, ein Feld, eine Methode usw. nicht explizit deklarieren.

    • Innerhalb der gleichen Pakete

    Eine Variable oder Methode, die ohne Zugriffsmodifizierer deklariert wurde, ist für jede andere class im selben Paket verfügbar. Die Felder in einer Schnittstelle sind implizit öffentlich statisch und die Methoden in einer Schnittstelle sind standardmäßig öffentlich.

    Hinweis

    Wir können die statischen Felder nicht überschreiben. Wenn Sie versuchen, sie zu überschreiben, wird kein Fehler angezeigt, aber es funktioniert nicht, was wir außer.

    Verwandte Antworten

    • Überschreiben von statischen Methoden in Java

    Referenzen Links

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

    Der Unterschied liegt in den bereits vorhandenen Links, aber die zu verwendenden Links ergeben sich in der Regel aus dem “Grundsatz des geringsten Wissens”. Erlaube nur die geringste Sichtbarkeit, die benötigt wird.

    Privat : Nur eingeschränkter Zugriff auf die class

    Standard (kein Modifikator) : Eingeschränkter Zugriff auf class und Paket

    Geschützt : Eingeschränkter Zugriff auf class, Paket und Unterklassen (sowohl innerhalb als auch außerhalb des Pakets)

    Öffentlich : Zugänglich für class, Paket (alle) und Unterklassen … Kurz gesagt, überall.

    Zugriffsmodifizierer in Java

    Java-Zugriffsmodifikatoren werden verwendet, um die Zugriffssteuerung in Java bereitzustellen.

    1. Standard:

    Zugänglich nur für die classn im selben Paket.

    Beispielsweise,

     // 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 } } 

    Dieser Zugang ist eingeschränkter als öffentlich und geschützt, aber weniger eingeschränkt als privat.

    2. Öffentlich

    Kann von überall zugegriffen werden. (Globaler Zugang)

    Beispielsweise,

     // 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(); } } 

    Ausgabe: Hallo

    3. Privat

    Zugänglich nur innerhalb derselben class.

    Wenn Sie versuchen, auf private Mitglieder einer class in einer anderen zuzugreifen, wird der Kompilierungserrors ausgetriggers. Beispielsweise,

     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. Geschützt

    Zugänglich nur für die classn im selben Paket und für die Unterklassen

    Beispielsweise,

     // 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(); } } 

    Ausgabe: Hallo

    Geben Sie eine Bildbeschreibung hier ein

    Zugriffsmodifizierer beschränken den Zugriff auf mehrere Ebenen.

    Öffentlich: Es ist im Grunde so einfach, wie Sie von jeder class aus zugreifen können, unabhängig davon, ob diese im gleichen Paket enthalten ist oder nicht.

    Wenn Sie auf dasselbe Paket zugreifen möchten, können Sie direkt darauf zugreifen. Wenn Sie sich jedoch in einem anderen Paket befinden, können Sie ein Objekt der class erstellen.

    Standard: Es ist im gleichen Paket von jeder der Paketklasse zugänglich.

    Um auf Sie zuzugreifen, können Sie ein Objekt der class erstellen. Sie können jedoch nicht außerhalb des Pakets auf diese Variable zugreifen.

    Geschützt: Sie können auf Variablen in demselben Paket sowie auf die Unterklasse in jedem anderen Paket zugreifen. Also ist es im Grunde Standard + Vererbtes Verhalten.

    Um auf das in der Basisklasse definierte geschützte Feld zuzugreifen, können Sie ein Objekt der Kindklasse erstellen.

    Privat: Es kann in derselben class zugegriffen werden.

    In nicht statischen Methoden können Sie direkt auf diese Referenz zugreifen (auch in Konstruktoren), aber in statischen Methoden müssen Sie Objekte der class erstellen.

    Sichtbar für das Paket. Der Standard. Es sind keine Modifizierer erforderlich.

    Sichtbar nur für die class ( privat ).

    Sichtbar für die Welt ( öffentlich ).

    Sichtbar für das Paket und alle Unterklassen ( geschützt ).

    Variablen und Methoden können ohne Modifikatoren deklariert werden, die aufgerufen werden. Standardbeispiele:

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

    Privater Zugriffsmodifizierer – privat:

    Auf Methoden, Variablen und Konstruktoren, die als privat deklariert sind, kann nur innerhalb der deklarierten class zugegriffen werden. Der private Zugriffsmodifikator ist die restriktivste Zugriffsebene. class und Schnittstellen können nicht privat sein.

    Auf Variablen, die als privat deklariert sind, kann außerhalb der class zugegriffen werden, wenn in der class öffentliche Getter-Methoden vorhanden sind.

    Die Verwendung des privaten Modifikators ist der Hauptweg, auf dem ein Objekt sich selbst kapselt und Daten von der Außenwelt verbirgt.

    Beispiele:

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

    Öffentlicher Zugriffsmodifikator – öffentlich:

    Auf eine deklarierte class, Methode, Konstruktor, Schnittstelle usw. kann von jeder anderen class zugegriffen werden. Daher kann auf Felder, Methoden, Blöcke, die innerhalb einer öffentlichen class deklariert sind, von jeder class zugegriffen werden, die zu dem Java-Universum gehört.

    Wenn sich die öffentliche class, auf die wir zugreifen möchten, jedoch in einem anderen Paket befindet, muss die öffentliche class noch importiert werden.

    Aufgrund der classnvererbung werden alle öffentlichen Methoden und Variablen einer class von ihren Unterklassen geerbt.

    Beispiel:

     public void cal(){ } 

    Geschützter Zugriffsmodifizierer – geschützt:

    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:

    • Listenpunkt
    • private
    • default (package)
    • protected
    • Öffentlichkeit

    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 .

    Hoffe das hilft!

    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…).