zugriffsmodifikatoren - zugriffsmodifizierer java




Was ist der Unterschied zwischen öffentlich, geschützt, privat und privat in Java? (16)

Gibt es in Java klare Regeln, wann jeder der Zugriffsmodifizierer verwendet werden soll, nämlich die Standardeinstellungen (Paket privat), public , protected und private , während class und interface und Vererbung vorgenommen wird?


Privatgelände

  • Methoden, Variablen und Konstruktoren

Auf private, deklarierte Methoden, Variablen und Konstruktoren kann nur innerhalb der deklarierten Klasse selbst zugegriffen werden.

  • Klasse und Schnittstelle

Privater Zugriffsmodifizierer ist die restriktivste Zugriffsebene. Klasse und Schnittstellen können nicht privat sein.

Hinweis

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

Geschützt

  • Klasse und Schnittstelle

Der geschützte Zugriffsmodifizierer kann nicht auf Klasse und Schnittstellen angewendet werden.

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

Hinweis

Der geschützte Zugriff gibt der Unterklasse die Möglichkeit, die Hilfsmethode oder -variable zu verwenden, während verhindert wird, dass eine nicht verwandte Klasse versucht, sie zu verwenden.

Öffentlichkeit

Auf öffentlich deklarierte Klassen, Methoden, Konstruktoren, Schnittstellen usw. kann von jeder anderen Klasse aus zugegriffen werden.

Auf Felder, Methoden und Blöcke, die in einer öffentlichen Klasse deklariert sind, kann daher von jeder Klasse, die zum Java-Universum gehört, zugegriffen werden.

  • Verschiedene Pakete

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

Aufgrund der Klassenvererbung werden alle öffentlichen Methoden und Variablen einer Klasse von ihren Unterklassen geerbt.

Default -No Schlüsselwort:

Der Standard-Zugriffsmodifizierer bedeutet, dass wir keinen Zugriffsmodifizierer für eine Klasse, ein Feld, eine Methode usw. explizit deklarieren.

  • Innerhalb der gleichen Pakete

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

Hinweis

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

Verwandte Antworten

Verweise Links

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


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

Privatgelände

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

Paket privat

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

Geschützt

Package Private + kann von Unterklassen oder Package-Mitgliedern angezeigt werden.

Öffentlichkeit

Jeder kann es sehen.

Published

Sichtbar außerhalb des Codes, den ich kontrolliere. (Obwohl es keine Java-Syntax ist, ist es für diese Diskussion wichtig).

C ++ definiert eine zusätzliche Ebene, die "Freund" genannt wird, und je weniger Sie davon wissen, desto besser.

Wann sollten Sie was verwenden? Die ganze Idee ist die Kapselung, um Informationen zu verbergen. So weit wie möglich möchten Sie die Details Ihrer Benutzer verbergen. Warum? Denn dann können Sie sie später ändern und den Code von niemandem brechen. Auf diese Weise können Sie Fehler optimieren, umgestalten, umgestalten und korrigieren, ohne sich Sorgen zu machen, dass jemand den gerade überarbeiteten Code verwendet hat.

Faustregel besagt, 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. Machen Sie nur das, was für den Benutzer unbedingt erforderlich ist, öffentlich. Machen Sie jedes Detail, das Sie öffentlich machen, zu Ihrer Fähigkeit, das System neu zu gestalten.

Wenn Sie möchten, dass Benutzer Verhalten anpassen können, anstatt Interns öffentlich zu machen, damit sie diese überschreiben können, ist es oft eine bessere Idee, diese Eingeweide in ein Objekt zu integrieren und diese Schnittstelle öffentlich zu machen. Auf diese Weise können sie einfach ein neues Objekt einfügen. Wenn Sie zum Beispiel einen CD-Player schreiben und das Bit "Informationen über diese CD suchen" anpassbar machen möchten, anstatt diese Methoden öffentlich zu machen, würden Sie die gesamte Funktionalität in ein eigenes Objekt einfügen und nur Ihren Objekt-Getter / -Setter öffentlich machen . So geizig zu sein, wenn man den Bauch offenlegt, fördert eine gute Zusammensetzung und Trennung der Anliegen

Persönlich bleibe ich nur mit "privat" und "öffentlich". Viele OO-Sprachen haben das einfach. "Geschützt" kann praktisch sein, aber es ist wirklich ein Betrug. Sobald eine Benutzeroberfläche mehr als privat ist, hat sie keine Kontrolle mehr, und Sie müssen im Code anderer Benutzer nach Verwendungsmöglichkeiten suchen.

Hier kommt die Idee von "veröffentlicht" zum Tragen. Wenn Sie eine Schnittstelle ändern (umgestalten), müssen Sie den gesamten Code finden, der sie verwendet, und auch den ändern. Wenn die Schnittstelle privat ist, ist das kein Problem. Wenn es geschützt ist, müssen Sie alle Ihre Unterklassen finden. Wenn es öffentlich ist, müssen Sie den Code finden, der Ihren Code verwendet. Dies ist manchmal möglich, wenn Sie beispielsweise an einem Unternehmenscode arbeiten, der nur für den internen Gebrauch bestimmt ist. Dabei ist es egal, ob eine Schnittstelle öffentlich ist. Sie können den gesamten Code aus dem Unternehmens-Repository herausholen. Wenn eine Schnittstelle jedoch "veröffentlicht" ist und Code verwendet wird, der außerhalb Ihrer Kontrolle liegt, werden Sie abgehackt. Sie müssen diese Schnittstelle oder den Code zum Schutz vor Bedrohungen unterstützen. Sogar geschützte Schnittstellen können als veröffentlicht betrachtet werden (deshalb kümmere ich mich nicht um geschützte Schnittstellen).

Viele Sprachen empfinden den hierarchischen Charakter von public / protected / private als zu einschränkend und nicht im Einklang mit der Realität. Zu diesem Zweck gibt es das Konzept einer Merkmalklasse , aber das ist eine andere Show.


Der Unterschied ist in den bereits vorhandenen Links zu finden, die jedoch zu verwenden sind, beruht auf dem "Prinzip des geringsten Wissens". Lassen Sie nur die geringste Sichtbarkeit zu, die erforderlich ist.


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

  • Nehmen wir an, wir haben 2 Klassen. Father und Son , jeweils in einem eigenen Paket:

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

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

    1. Innerhalb einer Klasse, die sich in demselben 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, über die aktuelle Instanz oder über die aktuelle Instanz:

      package sonpackage;
      
      public class Son extends Father
      {
          public void sonMethod()
          {
              this.foo();
              super.foo();
          }
      }
      
    3. Auf einer Referenz, deren Typ dieselbe Klasse 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. Auf einer Referenz, deren Typ die übergeordnete Klasse ist und sich innerhalb des Pakets befindet, in der foo() definiert ist ( fatherpackage ) [Dies kann in Kontext-Nr. 1]:

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

    1. Auf einer Referenz, deren Typ die übergeordnete Klasse ist und sich außerhalb des Pakets befindet, in der foo() definiert ist (" fatherpackage ):

      package sonpackage;
      
      public class Son extends Father
      {
          public void sonMethod(Father f)
          {
              f.foo(); // compilation error
          }
      }
      
    2. Eine Nicht-Unterklasse innerhalb eines Pakets einer Unterklasse (Eine Unterklasse erbt die geschützten Member 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
          }
      }
      

Es ist eigentlich etwas komplizierter als ein einfaches Raster zeigt. Das Raster zeigt an, ob ein Zugriff erlaubt ist, aber was genau ist ein Zugriff? Zugriffsebenen interagieren auf komplexe Weise mit verschachtelten Klassen und Vererbung.

Der "Standard" -Zugriff (angegeben durch das Fehlen eines Schlüsselworts) wird auch als package-private . Ausnahme: In einer Schnittstelle bedeutet kein Modifikator den öffentlichen Zugriff. andere Modifikatoren als public sind verboten. Enumerationskonstanten sind immer öffentlich.

Zusammenfassung

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

  • Member ist private : Nur wenn member innerhalb derselben Klasse wie aufrufender Code definiert ist.
  • Mitglied ist paket privat: Nur wenn der aufrufende Code innerhalb des Pakets liegt, das das Mitglied unmittelbar einschließt.
  • Member ist protected : Das gleiche Paket oder wenn member in einer Superklasse der Klasse definiert ist, die den aufrufenden Code enthält.
  • Mitglied ist public : Ja.

Für welche Zugangsdaten gilt

Lokale Variablen und Formalparameter können keine Zugriffspezifizierer annehmen. Da sie von außen nach den Regeln für das Scoping von außen unzugänglich sind, sind sie praktisch privat.

Für Klassen im oberen Bereich sind nur public und package-private zulässig. Diese Designauswahl ist vermutlich darauf zurückzuführen, dass protected und private Paketebene überflüssig wäre (es gibt keine Vererbung von Paketen).

Alle Zugriffspezifizierer sind für Klassenmitglieder (Konstruktoren, Methoden und statische Memberfunktionen, verschachtelte Klassen) möglich.

Verwandte: Java-Klassenzugänglichkeit

Auftrag

Die Zugangsdaten können streng geordnet werden

public> protected> package-private> privat

was bedeutet, dass public den meisten Zugang bietet, private den geringsten. Jede Referenz, die für ein privates Mitglied möglich ist, gilt auch für ein Paket-privates Mitglied. Alle Verweise auf ein Package-Private-Member gelten für ein geschütztes Member und so weiter. (Das Erteilen des Zugriffs auf geschützte Mitglieder an andere Klassen im selben Paket wurde als Fehler angesehen.)

Anmerkungen

  • Die Methoden einer Klasse dürfen auf private Member anderer Objekte derselben Klasse zugreifen. Genauer gesagt, eine Methode der Klasse C kann auf private Member von C auf Objekte einer beliebigen Unterklasse von C zugreifen. Java unterstützt keine Einschränkung des Zugriffs pro Instanz, nur nach Klasse. (Vergleiche mit Scala, die es mit private[this] .)
  • Sie benötigen Zugriff auf einen Konstruktor, um ein Objekt zu erstellen. Wenn alle Konstruktoren privat sind, kann die Klasse nur durch Code erstellt werden, der innerhalb der Klasse lebt (normalerweise statische Factory-Methoden oder Initialisierer für statische Variablen). Ähnlich für Package-private oder geschützte Konstruktoren.
    • Nur wenn private Konstruktoren vorhanden sind, bedeutet dies auch, dass die Klasse nicht extern untergeordnet werden kann, da Java die Konstruktoren einer Unterklasse benötigt, um implizit oder explizit einen Superklassenkonstruktor aufzurufen. (Es kann jedoch eine verschachtelte Klasse enthalten, die es unterordnet.)

Innere Klassen

Sie müssen auch verschachtelte Bereiche berücksichtigen, z. B. innere Klassen. Ein Beispiel für die Komplexität ist, dass innere Klassen Mitglieder haben, die selbst Zugriffsmodifizierer annehmen können. Sie können also eine private innere Klasse mit einem öffentlichen Mitglied haben. kann auf das Mitglied zugegriffen werden? (Siehe unten.) Die allgemeine Regel besteht darin, den Umfang zu prüfen und rekursiv zu überlegen, ob Sie auf jede Ebene zugreifen können.

Dies ist jedoch recht kompliziert. Weitere Informationen finden Sie in der Java-Sprachspezifikation . (Ja, in der Vergangenheit gab es Compiler-Fehler.)

Betrachten Sie dieses Beispiel, um zu sehen, wie diese zusammenwirken. Es ist möglich, private innere Klassen zu "lecken"; 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:


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

Erklärungen

  • Ein privates Mitglied ( i ) ist nur innerhalb derselben Klasse zugänglich, in der es deklariert ist.

  • Ein Member ohne Zugriffsmodifizierer ( j ) ist nur innerhalb von Klassen im selben Paket zugänglich.

  • Ein geschütztes Member ( k ) ist in allen Klassen im selben Paket und in Unterklassen in anderen Paketen verfügbar.

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

Welchen Modifikator wählen?

Zugriffsmodifizierer sind ein Werkzeug, mit dem Sie versehentlich die Kapselung (*) brechen können. Fragen Sie sich, ob das Mitglied etwas für die Klasse, das Paket, die Klassenhierarchie oder überhaupt nicht für die interne ist, und wählen Sie die Zugriffsebene entsprechend.

Beispiele:

  • Ein field long internalCounter sollte wahrscheinlich privat sein, da es veränderlich ist und ein Implementierungsdetail enthält.
  • Eine Klasse, die nur in einer Factory-Klasse (im selben Paket) instanziiert werden sollte, sollte einen auf Pakete beschränkten Konstruktor haben, da es nicht möglich sein sollte, ihn direkt von außerhalb des Pakets aufzurufen.
  • Eine interne void beforeRender() -Methode, die direkt vor dem Rendern aufgerufen und als Hook in Unterklassen verwendet wird, sollte geschützt werden.
  • Eine void saveGame(File dst) -Methode, die vom GUI-Code aufgerufen wird, sollte public sein.

(*) Was genau ist Encapsulation?


Zugriffsmodifizierer beschränken den Zugriff auf mehreren Ebenen.

Öffentlich: Es ist im Grunde so einfach, wie Sie von jeder Klasse aus darauf zugreifen können, ob sich diese im selben Paket befindet oder nicht.

Wenn Sie sich in demselben Paket befinden, können Sie direkt darauf zugreifen. Wenn Sie sich jedoch in einem anderen Paket befinden, können Sie ein Objekt der Klasse erstellen.

Standard: Es kann von einer beliebigen Paketklasse aus im selben Paket aufgerufen werden.

Für den Zugriff können Sie ein Objekt der Klasse erstellen. Sie können jedoch nicht auf diese Variable außerhalb des Pakets zugreifen.

Geschützt: Sie können auf Variablen in demselben Paket sowie auf Unterklassen in jedem anderen Paket zugreifen. Im Grunde ist es default + Inherited verhalten.

Um auf ein geschütztes Feld zuzugreifen, das in der Basisklasse definiert ist, können Sie ein Objekt der untergeordneten Klasse erstellen.

Privat: Es kann in derselben Klasse zugegriffen werden.

Bei nicht statischen Methoden können Sie aufgrund dieser Referenz direkt zugreifen (auch in Konstruktoren), aber bei statischen Methoden müssen Sie ein Objekt der Klasse erstellen.


Das offizielle Tutorial kann für Sie von Nutzen sein.

            │ Class │ Package │ Subclass │ Subclass │ World
            │       │         │(same pkg)│(diff pkg)│ 
────────────┼───────┼─────────┼──────────┼──────────┼────────
public      │   +   │    +    │    +     │     +    │   +     
────────────┼───────┼─────────┼──────────┼──────────┼────────
protected   │   +   │    +    │    +     │     +    │         
────────────┼───────┼─────────┼──────────┼──────────┼────────
no modifier │   +   │    +    │    +     │          │    
────────────┼───────┼─────────┼──────────┼──────────┼────────
private     │   +   │         │          │          │    

+ : accessible
blank : not accessible

Privat : Eingeschränkter Zugang nur zum Unterricht

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

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

Öffentlich : Zugriff auf Klasse, Paket (alle) und Unterklassen ... Kurz gesagt, überall.


Zugriffsmodifizierer in Java.

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

1. Standard:

Nur für die Klassen in demselben Paket zugänglich.

Zum Beispiel,

// 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 Zugriff ist stärker eingeschränkt als öffentlich und geschützt, jedoch weniger als privat.

2. Öffentlich

Kann von überall aus aufgerufen werden. (Globaler Zugriff)

Zum Beispiel,

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

Nur innerhalb derselben Klasse zugänglich.

Wenn Sie versuchen, auf private Member einer Klasse in einer anderen Klasse zuzugreifen, wird ein Kompilierungsfehler ausgegeben. Zum Beispiel,

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

Nur für die Klassen im selben Paket und für die Unterklassen zugänglich

Zum Beispiel,

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


Davids Antwort gibt die Bedeutung jedes Zugriffsmodifizierers an. Ich würde vorschlagen, alle Klassen und die Methoden jeder Klasse, die für den externen Gebrauch (API) bestimmt sind, sowie alle anderen privaten Klassen öffentlich zu machen.

Im Laufe der Zeit entwickeln Sie ein Gefühl dafür, wann einige Klassen als private Pakete deklariert werden und wann bestimmte Methoden für die Verwendung in Unterklassen geschützt werden müssen.


Es geht um die Einkapselung (oder, wie Joe Phillips sagte, das geringste Wissen ).

Beginnen Sie mit dem restriktivsten (privat) und prüfen Sie, ob Sie später weniger restriktive Modifikatoren benötigen.

Wir alle verwenden Methoden- und Membermodifizierer wie private, public, ... aber zu wenig Entwickler verwenden Pakete, um Code logisch zu organisieren .

Zum Beispiel: Sie können sensible Sicherheitsmethoden in ein Sicherheitspaket packen. Fügen Sie dann eine öffentliche Klasse hinzu, die auf einige der sicherheitsbezogenen Codes in diesem Paket zugreift, aber das Paket anderer Sicherheitsklassen privat hält . Daher können andere Entwickler die öffentlich verfügbare Klasse nur außerhalb dieses Pakets verwenden (es sei denn, sie ändern den Modifikator). Dies ist kein Sicherheitsmerkmal, sondern führt Nutzung.

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

Eine andere Sache ist, dass Klassen, die sehr stark voneinander abhängig sind, im selben Paket enden und eventuell umgestaltet oder zusammengefügt werden, wenn die Abhängigkeit zu stark ist.

Wenn Sie im Gegenteil alles als öffentlich festlegen , ist nicht klar, worauf zugegriffen werden soll oder nicht, was dazu führen kann, dass viel Javadoc geschrieben wird (was über den Compiler nichts erzwingt).


Ich möchte nur ein Detail ansprechen, das äußerst häufig falsch ist, einschließlich der meisten Antworten auf dieser Seite. "Standard" -Zugriff (wenn kein Zugriffsmodifizierer vorhanden ist) ist nicht immer identisch mit package-private . Es hängt davon ab, was das Ding ist.

  • Nicht-Mitgliedstypen (dh Klassen, Enums, Schnittstellen und Annotationstypen, die nicht in einem anderen Typ deklariert sind) sind standardmäßig "package-private". ( JLS §6.6.1 )

  • Klassenmitglieder und Konstruktoren sind standardmäßig paketprivat. ( JLS §6.6.1 )

  • Enum-Konstruktoren sind standardmäßig privat . ( In der Tat, Enum contructors muss privat sein, und es ist ein Fehler , zu versuchen , sie öffentlich oder geschützt zu machen). Enumerationskonstanten sind public und erlauben keinen Zugriffsbezeichner. Andere Mitglieder von enums sind standardmäßig package-private. ( JLS §8.9 )

  • Alle Mitglieder von Schnittstellen und Anmerkungstypen sind standardmäßig öffentlich . (Mitglieder der Schnittstellen und Annotationstypen müssen tatsächlich öffentlich sein. Es ist ein Fehler, sie als privat oder geschützt zu kennzeichnen .) ( JLS §9.3 bis 9.5 )


Oft habe ich erkannt, dass das Erinnern an die Grundbegriffe jeder Sprache möglich ist, indem Analogien aus der realen Welt geschaffen werden. Hier ist meine Analogie zum Verständnis von Zugriffsmodifizierern in Java:

Nehmen wir an, Sie sind Student an einer Universität und haben einen Freund, der Sie am Wochenende besucht. Angenommen, es gibt eine große Statue des Gründers der Universität in der Mitte des Campus.

  • Wenn Sie ihn auf den Campus bringen, sehen Sie und Ihr Freund als erstes diese Statue. Das bedeutet, dass jeder, der auf dem Campus geht, die Statue ohne Erlaubnis der Universität betrachten kann. Dies macht die Statue als ÖFFENTLICH .

  • Als nächstes möchten Sie Ihren Freund zu Ihrem Wohnheim bringen, aber dafür müssen Sie ihn als Besucher registrieren. Das bedeutet, dass er einen Zugangspass erhält (der Ihrem entspricht), um in verschiedene Gebäude auf dem Campus zu gelangen. Dies würde seine Zugangskarte als GESCHÜTZT machen .

  • Ihr Freund möchte sich auf dem Campus-WLAN anmelden, verfügt jedoch nicht über die erforderlichen Anmeldeinformationen. Online kann er nur online sein, wenn Sie Ihr Login mit ihm teilen. (Denken Sie daran, dass jeder Student, der zur Universität geht, auch diese Anmeldeinformationen besitzt.) Dies würde Ihre Anmeldeinformationen als KEINE ÄNDERUNG festlegen .

  • Schließlich möchte Ihr Freund Ihren Fortschrittsbericht für das auf der Website veröffentlichte Semester lesen. Jeder Student hat jedoch sein eigenes Login, um auf diesen Bereich der Campus-Website zuzugreifen. Dies würde diese Berechtigungsnachweise als PRIVATE machen .

Hoffe das hilft!


Wenn Sie über Zugriffsmodifikatoren nachdenken, denken Sie nur auf diese Weise daran (gilt sowohl für Variablen als auch für Methoden ):

public-> von überall aus erreichbar
private-> nur innerhalb derselben Klasse zugänglich, in der sie deklariert ist

Nun entsteht die Verwirrung, wenn es um defaultund gehtprotected

default-> Es ist kein Schlüssel für Zugriffsmodifizierer vorhanden. Dies bedeutet, dass es ausschließlich im Paket der Klasse verfügbar ist. Nirgendwo außerhalb dieses Pakets kann darauf zugegriffen werden.

protected-> Etwas weniger streng als die defaultabgesehen von denselben Paketklassen, auf die Subklassen außerhalb des deklarierten Pakets zugreifen können.


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






access-modifiers