Jaka jest różnica między publicznym, chronionym, pakietem-prywatnym a prywatnym w Javie?

(Zastrzeżenie: nie jestem programistą Javy, jestem programistą Perla. Perl nie ma żadnych formalnych zabezpieczeń, dlatego chyba tak dobrze rozumiem problem:))

Private

Tak jak myślisz, tylko klasa , w której jest zadeklarowana, może ją zobaczyć.

Pakiet Prywatny

Może być widziany i używany tylko przez pakiet , w którym został zadeklarowany. Jest to wartość domyślna w Javie (co niektórzy postrzegają jako błąd).

Protected

Pakiet prywatny + puszka być widziane przez podklasy lub członka pakietu.

Public

Każdy może to zobaczyć.

Opublikowano

Widoczny poza kontrolą kodu. (Choć nie składnia Java, jest to ważne w tej dyskusji).

C++ definiuje dodatkowy poziom zwany "przyjacielem" i im mniej o tym wiesz, tym lepiej.

Kiedy należy używać czego? Cała idea to enkapsulacja w celu ukrycia informacji. Jak najbardziej chcesz ukryć szczegóły, jak coś jest zrobione od użytkowników. Dlaczego? Bo wtedy możesz je później zmienić i nie złamać niczyjego kodu. Pozwala to zoptymalizować, refakturować, przeprojektować i naprawić błędy bez obawy, że ktoś używał tego kodu, który właśnie zmieniłeś.

Więc, zasada jest, aby rzeczy tylko tak widoczne, jak muszą być. Zacznij od opcji prywatne i dodaj więcej widoczności tylko w razie potrzeby. Upublicznij tylko to, co jest absolutnie niezbędne, aby użytkownik wiedział, każdy szczegół, który upublicznisz, przeprojektować system.

Jeśli chcesz, aby użytkownicy mogli dostosowywać zachowania, zamiast upubliczniać wewnętrzne elementy, aby mogły je nadpisać, często lepszym pomysłem jest wepchnięcie tych wnętrzności do obiektu i upublicznienie tego interfejsu. W ten sposób mogą po prostu podłączyć nowy obiekt. Na przykład, jeśli piszesz odtwarzacz CD i chcesz, aby" idź Znajdź informacje o tej płycie " bit konfigurowalny, zamiast upubliczniać te metody, umieścisz całą tę funkcjonalność we własnym obiekcie i sprawisz, że tylko twój obiekt getter / setter public. W ten sposób bycie skąpym w eksponowaniu swoich wnętrzności zachęca do dobrego składu i oddzielania obaw

Osobiście trzymam się tylko "prywatnych" i "publicznych". Wiele języków właśnie to ma. "Chroniony" może być przydatny, ale to naprawdę oszustwo. Gdy interfejs jest więcej niż prywatny, jest poza Twoją kontrolą i musisz szukać kodu innych osób, aby znaleźć zastosowania.

Tutaj pojawia się idea "published". Zmiana interfejs (refaktoryzacja) wymaga, aby znaleźć cały kod, który go używa i to również zmienić. Jeśli interfejs jest prywatny, nie ma problemu. Jeśli jest chroniony, musisz znaleźć wszystkie swoje podklasy. Jeśli jest publiczny, musisz znaleźć cały kod, który używa Twojego kodu. Czasami jest to możliwe, na przykład, jeśli pracujesz nad kodem korporacyjnym, który jest tylko do użytku wewnętrznego, nie ma znaczenia, czy interfejs jest publiczny. Możesz pobrać cały kod z firmowego repozytorium. Ale jeśli interfejs jest "opublikowany" , jeśli istnieje kod wykorzystujący go poza Twoją kontrolą, to jesteś hasked. Musisz obsługiwać ten interfejs lub ryzykować złamanie kodu. Nawet chronione interfejsy można uznać za opublikowane (dlatego nie przejmuję się ochroną).

Wiele języków uważa hierarchiczny charakter public/protected / private za zbyt ograniczający i niezgodny z rzeczywistością. W tym celu istnieje koncepcja klasy cech , ale to kolejny pokaz.

Oto lepsza wersja tabeli. (Future proof z kolumną dla modułów.)

Objaśnienia

• Prywatny członek jest tylko dostępny w ramach tej samej klasy, jaką jest zadeklarowany.

• Członek z bez modyfikatora dostępu jest dostępny tylko w ramach klas w tym samym pakiecie.

• Członek protected jest dostępny we wszystkich klasach w tym samym pakiecie i w podklasach w innych pakietach.

• Element public jest dostępny dla wszystkich klas (chyba że znajduje się w module , który nie eksportuje pakietu, w którym jest zadeklarowany).

Jaki modyfikator wybrać?

Modyfikatory dostępu To narzędzie, które pomoże Ci zapobiec przypadkowemu przerwaniu enkapsulacji^(*). Zadaj sobie pytanie, czy chcesz, aby członek był czymś, co jest wewnętrzne w Klasa, pakiet, hierarchia klas lub w ogóle nie wewnętrzna i wybierz odpowiednio poziom dostępu.

Przykłady:

• pole {[0] } powinno być prywatne, ponieważ jest zmienne i zawiera szczegóły implementacji.
• klasa, która powinna być utworzona tylko w klasie factory (w tym samym pakiecie) powinna mieć konstruktor ograniczonego pakietu, ponieważ nie powinno być możliwe wywołanie go bezpośrednio spoza pakietu.
• Wewnętrzna void beforeRender() metoda zwana tuż przed renderowaniem i używane jako hook w podklasach powinny być chronione.
• Metoda void saveGame(File dst) wywoływana z kodu GUI powinna być Publiczna.

^{(*) czym dokładnie jest enkapsulacja?}

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

Prosta zasada. Zacznij od stwierdzenia, że wszystko jest prywatne. A następnie postęp w kierunku społeczeństwa, gdy pojawiają się potrzeby i projekt tego wymaga.

Podczas wystawiania członków zadaj sobie pytanie, czy wystawiasz wybory reprezentacji czy wybory abstrakcji. Pierwszy z nich jest czymś, czego chcesz uniknąć, ponieważ wprowadzi zbyt wiele zależności od rzeczywistej reprezentacji, a nie od jej obserwowalnego zachowania.

Jako ogólna zasada staram się unikać nadpisywania implementacji metod poprzez podklasowanie; zbyt łatwo spieprzyć logikę. Zadeklaruj abstrakcyjne metody chronione, jeśli chcesz, aby zostały nadpisane.

Użyj również adnotacji @ Override podczas nadpisywania, aby zapobiec uszkodzeniu podczas refaktoryzacji.

To właściwie trochę bardziej skomplikowane niż zwykła siatka pokazuje. Siatka informuje, czy dostęp jest dozwolony, ale co dokładnie stanowi dostęp? Ponadto poziomy dostępu oddziałują na zagnieżdżone klasy i dziedziczenie w złożony sposób.

Dostęp "domyślny" (określony przez brak słowa kluczowego) jest również wywoływany pakiet-prywatny. Wyjątek: w interfejsie brak modyfikatora oznacza dostęp publiczny; modyfikatory inne niż publiczne są zabronione. Stałymi Enum są zawsze publicznie.

Podsumowanie

Czy dostęp do członka z tym określnikiem dostępu jest dozwolony?

• Member to private: tylko wtedy, gdy member jest zdefiniowany w ramach tej samej klasy co kod wywołujący.
• Member jest pakietem prywatnym: tylko wtedy, gdy kod wywoławczy znajduje się w pakiecie natychmiast dołączającym.
• Member to protected: ten sam pakiet, lub jeśli member jest zdefiniowany w superklasie klasy zawierającej kod wywołujący.
• członkiem jest public: Tak.

Jakie dane dostępu mają zastosowanie do

Zmienne lokalne i parametry formalne nie mogą przyjmować specyfikacji dostępu. Ponieważ są one z natury niedostępne Na Zewnątrz zgodnie z zasadami ustalania zakresu, są one w rzeczywistości prywatne.

Dla klas z górnego zakresu dozwolone są tylko public i pakiet-prywatny. Ten wybór jest prawdopodobnie dlatego, że protected i private byłyby zbędne na poziomie pakietu (nie ma dziedziczenia pakietów).

Wszystkie specyfiki dostępu są możliwe na elementach klasy (konstruktory, metody i statyczne funkcje prętowe, klasy zagnieżdżone).

Powiązane: Java Class Accessibility

Zamówienie

Specyfikatory dostępu mogą być ściśle uporządkowane

Public > protected > package-private > private

Co oznacza, że public zapewnia największy Dostęp, private najmniej. Wszelkie możliwe odniesienia do członka prywatnego są również ważne dla członka prywatnego pakietu; każdy odniesienie do package-private member jest ważne na chronionym członku itd. (Przyznanie dostępu chronionym członkom do innych klas w tym samym pakiecie było uważane za błąd.)

Uwagi

• metody klasy są dozwolone do dostępu do prywatnych członków innych obiektów tej samej klasy. dokładniej, metoda klasy C może uzyskać dostęp do prywatnych członków C na obiektach dowolnej podklasy C. Java nie obsługuje ograniczania dostępu przez instancję, tylko przez klasy. (Porównaj ze scalą, która obsługuje ją za pomocą private[this].)
• do zbudowania obiektu potrzebny jest dostęp do konstruktora. Tak więc, jeśli wszystkie konstruktory są prywatne, klasa może być skonstruowana tylko za pomocą kodu żyjącego w obrębie klasy (zazwyczaj statyczne metody fabryczne lub inicjalizatory zmiennych statycznych). Podobnie w przypadku konstruktorów typu package-private lub protected.
  • tylko posiadanie prywatnych konstruktorów oznacza również, że klasa nie może być podklasowana zewnętrznie, ponieważ Java wymaga konstruktory podklasy do niejawnego lub jawnego wywołania konstruktora superklasy. (Może jednak zawierać zagnieżdżoną klasę, która ją podklasuje.)

Klasy wewnętrzne

Należy również wziąć pod uwagęzagnieżdżone zakresy, takie jak Klasy wewnętrzne. Przykładem złożoności jest to, że wewnętrzne klasy mają członków, które same mogą przyjmować modyfikatory dostępu. Więc możesz mieć prywatną klasę wewnętrzną z członkiem publicznym; czy członek może być dostępny? (Patrz poniżej.) The ogólna zasada jest, aby spojrzeć na zakres i myśleć rekurencyjnie, aby zobaczyć, czy można uzyskać dostęp do każdego poziomu.

Jest to jednak dość skomplikowane i aby uzyskać szczegółowe informacje, zapoznaj się ze specyfikacją języka Java. (Tak, w przeszłości zdarzały się błędy kompilatora.)

Aby poznać smak interakcji, rozważ ten przykład. Możliwe jest "wyciekanie" prywatnych klas wewnętrznych; zwykle jest to Ostrzeżenie: {]}

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

Wyjście kompilatora:

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

Niektóre pokrewne pytania:

• Java-dostępność metod wewnątrz pakietu-Klasa prywatna?

Jako zasada:

• private : Zakres klas.
• default (or package-private): Zakres pakietu.
• protected : Zakres pakietu + child (podobnie jak pakiet, ale możemy go podklasować z różnych pakietów). Chroniony modyfikator zawsze zachowuje relację "rodzic-dziecko".
• public : wszędzie.

W rezultacie, jeśli podzielimy prawo dostępu na trzy prawa:

• (D) irect (wywołanie z metody wewnątrz tej samej klasy).
• (R)eference (wywołaj metodę używając odwołania do klasy lub składni "kropki").
• (I) nheritance (poprzez podklasowanie).

Wtedy mamy prostą tabelę:

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

W bardzo krótkim

• public: dostępne zewsząd.
• protected: dostępne dla klas tego samego pakietu i podklas znajdujących się w dowolnym pakiecie.
• default (no modifier specified): dostępne przez klasy tego samego pakietu.
• private: dostępne tylko w ramach tej samej klasy.

Najbardziej niezrozumianym modyfikatorem dostępu w Javie jest protected. Wiemy, że jest podobny do domyślnego modyfikatora z jednym wyjątkiem, w którym podklasy mogą go zobaczyć. Ale jak? Oto przykład, który, miejmy nadzieję, wyjaśnia zamieszanie: {]}

• Załóżmy, że mamy 2 klasy; Father i Son, każda w swoim własnym pakiecie:

  package fatherpackage;
  
  public class Father
  {
  
  }
  
  -------------------------------------------
  
  package sonpackage;
  
  public class Son extends Father
  {
  
  }
  

• Dodajmy metodę chronioną foo() do Father.

  package fatherpackage;
  
  public class Father
  {
      protected void foo(){}
  }
  

• Metodę foo() można wywołać w 4 konteksty:

  1. Wewnątrz klasy, która znajduje się w tym samym pakiecie, gdzie foo() jest zdefiniowana (fatherpackage):

     package fatherpackage;
     
     public class SomeClass
     {
         public void someMethod(Father f, Son s)
         {
             f.foo();
             s.foo();
         }
     }
     

  2. Wewnątrz podklasy, na bieżącej instancji poprzez this lub super:

     package sonpackage;
     
     public class Son extends Father
     {
         public void sonMethod()
         {
             this.foo();
             super.foo();
         }
     }
     

  3. Na referencji, której typ jest tą samą klasą:

     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. W odniesieniu, którego typ jest klasą nadrzędną i jest wewnątrz pakietu, w którym zdefiniowano foo() (fatherpackage) [Może to być zawarte w kontekście no. 1]:

     package fatherpackage;
     
     public class Son extends Father
     {
         public void sonMethod(Father f)
         {
             f.foo();
         }
     }
     

• Poniższe sytuacje nie są ważne.

  1. Na referencji, której typ jest klasą nadrzędną i jest poza pakietem, w którym foo() jest zdefiniowany (fatherpackage):

     package sonpackage;
     
     public class Son extends Father
     {
         public void sonMethod(Father f)
         {
             f.foo(); // compilation error
         }
     }
     

  2. Nie-podklasa wewnątrz pakietu podklasy (podklasa dziedziczy chronione członkowie od swojego rodzica i czyni je prywatnymi do nie-podklasy):

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

Private

• Metody, zmienne i konstruktory

metody, zmienne i konstruktory, które są zadeklarowane jako prywatne, mogą być dostępne tylko w samej zadeklarowanej klasie.

• klasa i interfejs

modyfikator dostępu prywatnego jest najbardziej restrykcyjnym poziomem dostępu. Klasa i interfejsy nie mogą być prywatne.

Uwaga

dostępne są zmienne zadeklarowane jako prywatne poza klasą, jeśli w klasie są obecne publiczne metody getter. Zmienne, metody i konstruktory, które są zadeklarowane jako chronione w klasie nadrzędnej, mogą być dostępne tylko dla podklas w innym pakiecie lub dowolnej klasie w pakiecie klasy protected members.

Protected

• Klasa I interfejs

modyfikator protected access nie może być zastosowany do klasy i interfejsy.

metody, pola mogą być zadeklarowane jako chronione, jednak metody i pola w interfejsie nie mogą być zadeklarowane jako chronione.

Uwaga

Protected access daje podklasie możliwość użycia metody pomocniczej lub zmiennej, jednocześnie uniemożliwiając niezwiązanym klasom użycie jej.

Public

Klasa, metoda, konstruktor, interfejs itp. zadeklarowana jako Publiczna może być dostępne z każdej innej klasy.

dlatego pola, metody, bloki zadeklarowane wewnątrz klasy publicznej mogą być dostępne z dowolnej klasy należącej do uniwersum Java.

• Różne Opakowania

Jeśli jednak Klasa Publiczna, do której chcemy uzyskać dostęp, znajduje się w innym pakiecie, to klasa publiczna nadal musi zostać zaimportowana.

ze względu na dziedziczenie klas, wszystkie publiczne metody i zmienne klasy są dziedziczone przez podklasy.

Default-No keyword:

domyślny modyfikator dostępu oznacza, że nie deklarujemy jawnie modyfikatora dostępu dla klasy, pola, metody, itd.

• w tych samych opakowaniach

zmienna lub metoda zadeklarowana bez modyfikatora kontroli dostępu jest dostępna dla innej klasy w tym samym pakiecie. Pola w interfejsie są domyślnie public static final a metody w interfejsie są domyślnie publiczne.

Uwaga

Nie możemy nadpisać pól statycznych.jeśli spróbujesz nadpisać, nie wyświetli żadnego błędu ale to nie działa jak my.

Podobne Odpowiedzi

• nadpisywanie metod statycznych w Javie

Bibliografia linki

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

Różnicę można znaleźć w linkach już podanych, ale które z nich użyć zwykle sprowadza się do "zasady najmniejszej wiedzy". Zezwalaj tylko na najmniej widoczną widoczność, która jest potrzebna.

Private : ograniczony dostęp tylko do klasy

Default (no modifier) : ograniczony dostęp do klasy i pakietu

Protected : ograniczony dostęp do klasy, pakietu i podklasy (zarówno wewnątrz, jak i na zewnątrz pakietu)

Public : Dostępny dla klas, pakietów (wszystkich) i podklas... Krótko mówiąc, wszędzie.

Modyfikatory dostępu w Javie.

1. Domyślnie:

Dostępne tylko dla klas w tym samym pakiecie.

Na przykład,

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

2. Public

Mogą być dostępne z dowolnego miejsca. (Dostęp Globalny)

Na przykład,

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

Wyjście: Hello

3. Private

Dostępne tylko wewnątrz tej samej klasy.

Jeśli spróbujesz uzyskać dostęp do prywatnych członków jednej klasy w innej, spowoduje to błąd kompilacji. Na przykład,

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. Protected

Dostępne tylko dla klas w tym samym pakiecie i podklas

Na przykład,

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

Wyjście: Hello

Modyfikatory dostępu służą do ograniczania dostępu na kilku poziomach.

Public: jest to w zasadzie tak proste, jak możesz uzyskać dostęp z dowolnej klasy, niezależnie od tego, czy jest ona w tym samym pakiecie, czy nie.

Aby uzyskać dostęp, jeśli jesteś w tym samym pakiecie, możesz uzyskać dostęp bezpośrednio, ale jeśli jesteś w innym pakiecie, możesz utworzyć obiekt klasy.

Domyślnie: jest dostępny w tym samym pakiecie z dowolnej klasy pakietu.

Aby uzyskać dostęp, możesz utworzyć obiekt klasy. Ale nie można uzyskać dostępu do tej zmiennej poza pakietem.

Protected: możesz uzyskać dostęp do zmiennych w tym samym pakiecie, jak również do podklasy w każdym innym pakiecie. więc w zasadzie jest to default + dziedziczone zachowanie.

Aby uzyskać dostęp do pola chronionego zdefiniowanego w klasie bazowej, można utworzyć obiekt klasy potomnej.

Private: to może być dostęp w tej samej klasie.

W metodach niestatycznych można uzyskać dostęp bezpośrednio z powodu tego reference (również w konstruktorach) ale aby uzyskać dostęp w metodach statycznych należy utworzyć obiekt klasy.

Widoczny na opakowaniu. Domyślne. Nie są potrzebne modyfikatory.

Widoczne tylko dla klasy (private ).

Widoczny dla świata (publiczny ).

Widoczne dla pakietu i wszystkich podklas (chronione ).

Zmienne i metody mogą być deklarowane bez wywoływanych modyfikatorów. Domyślne przykłady:

String name = "john";

public int age(){
    return age;
}

Modyfikator dostępu prywatnego-prywatny:

Metody, zmienne i konstruktory, które są zadeklarowane jako prywatne, mogą być dostęp do zadeklarowanej klasy. Modyfikator dostępu prywatnego jest najbardziej restrykcyjnym poziomem dostępu. Klasa i interfejsy nie mogą być prywatne.

Zmienne, które są zadeklarowane jako prywatne, mogą być dostępne poza klasą, jeśli w klasie są obecne publiczne metody getter.

Użycie modyfikatora prywatnego jest głównym sposobem, w jaki obiekt zamyka się i ukrywa dane ze świata zewnętrznego.

Przykłady:

Public class Details{

    private String name;

    public void setName(String n){
        this.name = n;
    }

    public String getName(){
        return this.name;
    }
}

Public access modifier-public:

A Klasa, metoda, konstruktor, interfejs itp. zadeklarowana publiczna może być dostępna z dowolnej innej klasy. Dlatego pola, metody, bloki zadeklarowane wewnątrz klasy publicznej mogą być dostępne z dowolnej klasy należącej do uniwersum Java.

Jednakże, jeśli Klasa Publiczna, do której chcemy uzyskać dostęp, znajduje się w innym pakiecie, to klasa publiczna nadal musi zostać zaimportowana.

Ze względu na dziedziczenie klas, wszystkie publiczne metody i zmienne klasy są dziedziczone przez jej podklasy.

Przykład:

public void cal(){

}

Protected access modifier-protected:

Zmienne, metody i konstruktory, które są zadeklarowane jako chronione w klasie nadrzędnej, mogą być dostępne tylko dla podklas w innym pakiecie lub dowolnej klasie w pakiecie klasy protected members.

Modyfikator protected access nie może być zastosowany do klas i interfejsów. Metody, pola mogą być deklarowane jako chronione, jednak metody i pola w interfejsie nie mogą być deklarowane chronione.

Protected access daje podklasie szansę użycia metody pomocniczej lub zmiennej, jednocześnie uniemożliwiając niezwiązanym klasom użycie jej.

class Van{

    protected boolean speed(){

    }
}

class Car{
    boolean speed(){
    }

}

• Public - dostępne z dowolnego miejsca w aplikacji.

• Default - dostępne z pakietu.

• Protected - dostępne z pakietu i podklas w innym pakiecie. jak również

• Private - dostępne tylko z jego klasy.

Chcę tylko odnieść się do szczegółów, które są bardzo często mylone, w tym przez większość odpowiedzi na tej stronie. "domyślny" dostęp (gdy nie ma modyfikatora dostępu) nie zawsze jest taki sam jak pakiet-prywatny . To zależy, co to jest.

• Typy niebędące członkami (to znaczy klasy, liczby, interfejsy i typy adnotacji nie zadeklarowane wewnątrz innego typu) są domyślnie package-private. (JLS §6.6.1)

• Członkowie klas i konstruktory są domyślnie package-private. (JLS §6.6.1)

• Konstruktory Enum są domyślnie Prywatne . (Rzeczywiście, enum contructors muszą być prywatne, a próba upublicznienia ich lub ochrony jest błędem). Stałe Enum są publiczne i nie zezwalają na dostęp. Pozostałe elementy enum są domyślnie package-private. (JLS §8.9)

• Wszystkie elementy interfejsów i typów adnotacji są publiczne przez default . (Rzeczywiście, członkowie interfejsów i typów adnotacji muszą być publiczne, a próba uczynienia ich prywatnymi lub chronionymi jest błędem.) (JLS §9.3 to 9.5)

Ta strona dobrze pisze o chronionym & domyślnym modyfikatorze dostępu

.... Protected: Protected access modifier jest trochę trudne i można powiedzieć, że jest superset domyślnego modyfikatora dostępu. Członkowie chronieni są tacy sami jak członkowie domyślni, jeśli chodzi o dostęp w tym samym pakiecie. Różnica polega na tym, że protected members są również dostępne dla podklas klasy, w której członek jest zadeklarowany, które znajdują się poza pakietem, w którym Klasa rodzica jest obecna.

Ale te chronione czĹ 'onki sÄ ..." dostÄ ™ pne poza pakietem tylko poprzez dziedziczenie". można uzyskać dostęp do chronionego członka klasy w jej podklasie obecnej w innym pakiecie bezpośrednio tak, jakby członek był obecny w samej podklasie. Ale ten chroniony członek nie będzie dostępny w podklasie poza pakietem, używając referencji klasy nadrzędnej. ....

Odpowiedź Dawida zawiera znaczenie każdego modyfikatora dostępu. Jeśli chodzi o to, kiedy używać każdej z nich, sugerowałbym upublicznienie wszystkich klas i metod każdej z nich, które są przeznaczone do użytku zewnętrznego (jej API), a Wszystko inne prywatne.

Z czasem rozwinie się poczucie, kiedy sprawić, by niektóre klasy były prywatne, a kiedy zadeklarować pewne metody chronione do użycia w podklasach.

• widoczny na opakowaniu. default . Nie są potrzebne modyfikatory.
• widoczny tylko dla klasy; prywatny .
• widzialny dla świata; publiczny .
• widoczny dla pakietu i wszystkich podklas; chroniony .

porozmawiajmy więc o kontroli dostępu i dziedziczeniu Następujące zasady dla metod dziedziczonych są następujące:

• metody zadeklarowane public w superklasie również muszą być publiczne we wszystkich podklasy.
• metody zadeklarowane protected w klasie nadrzędnej muszą być protected lub public w podklasach; nie mogą być prywatne.
• metody zadeklarowane bez kontroli dostępu (nie użyto modyfikatora) mogą być deklarowany jako bardziej prywatny w podklasach.
• metody zadeklarowane private nie są w ogóle dziedziczone, więc nie ma rządzić za nich.

Uwaga: jest to tylko uzupełnienie dla zaakceptowanej odpowiedzi.

Jest to związane z modyfikatorami dostępu Java .

From Modyfikatory Dostępu Java :

Modyfikator dostępu Java określa, które klasy mogą uzyskać dostęp do danego klasa i jej pola, konstruktory i metody. Modyfikatory dostępu mogą być określone oddzielnie dla klasy, jej konstruktorów, pól i metody. Modyfikatory dostępu Java są również czasami określane w daily mowa jako Java access specifiiers, ale poprawna nazwa to Java access modyfikatory. Klasy, pola, konstruktory i metody mogą mieć jedną z cztery różne modyfikatory dostępu Javy:

• pozycja listy
• private
• default (pakiet)
• protected
• public

From Controlling Access to Members of a Class tutoriale:

Modyfikatory poziomu dostępu określają, czy inne klasy mogą używać określone pole lub wywołanie określonej metody. Istnieją dwa poziomy "Kontrola dostępu": {]}

• na najwyższym poziomie-public, lub package-private (bez jawnego modyfikatora).
• na poziomie member-public, private, protected, lub package-private (bez jawnego modyfikatora).

Klasa może być zadeklarowana z modyfikatorem public, w którym to przypadku klasa jest widoczna dla wszystkich klas wszędzie. Jeśli klasa nie ma modyfikatora (domyślna, znana również jako package-private), jest widoczny tylko w ramach własnego pakietu

Poniższa tabela pokazuje dostęp do członków dozwolonych przez każdego modyfikator.

╔═════════════╦═══════╦═════════╦══════════╦═══════╗
║ 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     ║
╚═════════════╩═══════╩═════════╩══════════╩═══════╝

Pierwsza kolumna danych wskazuje, czy sama klasa ma dostęp do członek określony przez poziom dostępu. Jak widać, Klasa zawsze ma dostęp do swoich członków. Druga kolumna wskazuje, czy klas w tym samym pakiecie co Klasa (niezależnie od ich rodziców) mają dostęp do członka. Trzecia kolumna wskazuje czy podklasy klasy zadeklarowanej poza tym pakietem mają dostęp do członka. Czwarta kolumna wskazuje, czy wszystkie klasy mieć dostęp do członka.

Poziomy dostępu wpływają na Ciebie na dwa sposoby. Po pierwsze, gdy używasz klas, które pochodzą z innego źródła, np. z klas na platformie Java, poziomy dostępu określają, którzy członkowie tych klas są twoimi własnymi klasy mogą korzystać. Po drugie, kiedy piszesz klasę, musisz zdecydować jaki poziom dostępu zmienna członkowska i każda metoda w twojej klasie powinienem był.

Public Protected Default I private są modyfikatorami dostępu.

Są przeznaczone do enkapsulacji lub ukrywania i pokazywania zawartości klasy.

1. klasa może być Publiczna lub domyślna
2. Członkowie klasy mogą być publiczne, chronione, domyślne lub prywatne.

Prywatny nie jest dostępny poza klasą Domyślnie jest dostępna tylko w pakiecie. Protected in package, jak również każdej klasy, która go rozszerza. Publiczna jest otwarta dla wszystkich.

Normalnie zmienne członkowskie są zdefiniowane jako prywatne, ale metody członkowskie są publiczne.

Często zdałem sobie sprawę, że zapamiętywanie podstawowych pojęć dowolnego języka może być możliwe poprzez tworzenie rzeczywistych analogii. Oto moja analogia do zrozumienia modyfikatorów dostępu w Javie:

Załóżmy, że jesteś studentem uniwersytetu i masz przyjaciela, który odwiedzi cię w weekend. Załóżmy, że w środku kampusu znajduje się wielki pomnik założyciela Uniwersytetu.

• Kiedy przyprowadzasz go na kampus, pierwszą rzeczą, która ty i twój przyjaciel widzicie ten posąg. Oznacza to, że każdy, kto chodzi po kampusie, może spojrzeć na pomnik bez zgody Uniwersytetu. To sprawia, że posąg jest publiczny .

• Następnie chcesz zabrać swojego przyjaciela do akademika, ale do tego musisz zarejestrować go jako gościa. Oznacza to, że dostaje przepustkę (która jest taka sama jak twoja), aby dostać się do różnych budynków na kampusie. To uczyniłoby jego kartę dostępu jako chronione .

• Twój znajomy chce zalogować się do sieci Wi-Fi kampusu, ale nie ma żadnych poświadczeń, aby to zrobić. Jedyny sposób, aby uzyskać dostęp do Internetu, to udostępnienie mu loginu. (Pamiętaj, każdy student, który idzie na uniwersytet, również posiada te dane logowania). To sprawi, że Twoje dane logowania staną się bez modyfikatora .

• Na koniec Twój znajomy chce przeczytać raport z postępów w semestrze, który jest zamieszczony na stronie internetowej. Jednakże, każdy student ma swój własny login, aby uzyskać dostęp do tej sekcji strony internetowej kampusu. To uczyniłoby te referencje prywatnymi .

Mam nadzieję, że to pomoże!

Gdy myślisz o modyfikatorach dostępu, pomyśl o tym w ten sposób (dotyczy zarówno zmiennych, jak i metod):

public --> dostępne z każdego miejsca
private --> dostępny tylko w ramach tej samej klasy, gdzie jest zadeklarowany

Teraz pojawia się zamieszanie, jeśli chodzi o default i protected

default --> nie ma słowa kluczowego modyfikatora dostępu. Oznacza to, że jest on dostępny wyłącznie w ramach pakietu klasy. nigdzie poza tym pakiet można uzyskać dostęp.

protected --> nieco mniej rygorystyczny niż default i poza tymi samymi klasami pakietów, dostęp do niego mogą uzyskać podklasy spoza pakietu, który jest deklarowany.

Chodzi o enkapsulację (lub jak stwierdził Joe Phillips, najmniej wiedzy ).

Zacznij od najbardziej restrykcyjnych (prywatnych) i sprawdź, czy później potrzebujesz mniej restrykcyjnych modyfikatorów.

Wszyscy używamy modyfikatorów Method i member, takich jak private, public, ... jednak za mało programistów używa pakietów do logicznego porządkowania kodu .

Na przykład: Możesz umieścić wrażliwe metody zabezpieczeń w pakiecie "bezpieczeństwo". Następnie umieścić klasę publiczną, która uzyskuje dostęp do niektórych kodów związanych z bezpieczeństwem w tym pakiecie, ale zachowuje inne klasy bezpieczeństwa Pakiet prywatny . W ten sposób inni deweloperzy będą mogli używać publicznie dostępnej klasy spoza tego pakietu (chyba że zmienią modyfikator). Nie jest to funkcja zabezpieczająca, ale poprowadzi użycie.

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

Inną rzeczą jest to, że klasy, które wiele od siebie zależą, mogą skończyć w tym samym pakiecie i mogą być w końcu refakturowane lub scalone, jeśli zależność jest zbyt silny.

Jeśli natomiast ustawisz wszystko jako public , nie będzie jasne, co powinno być dostępne, a co nie, co może prowadzić do napisania dużej ilości javadoc (która nie wymusza niczego przez kompilator...).