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

W Javie istnieją jasne zasady kiedy użyć każdego z modyfikatorów dostępu, czyli domyślne (pakiet prywatny) public, protectedoraz private, jednocześnie class, a interfacei radzenia sobie z dziedziczenia?

Oficjalny samouczek może ci się przydać.

______________________________________________________________
| │ Klasa │ Pakiet │ Podklasa │ Podklasa │ Świat |
| │ │ │ (same pkg) │ (diff pkg) │ |
| ───────────┼───────┼─────────┼──────────┼──────── ──┼──────── |
| public │ + │ + │ + │ + │ + | 
| ───────────┼───────┼─────────┼──────────┼──────── ──┼──────── |
| chronione │ + │ + │ + │ + │ | 
| ───────────┼───────┼─────────┼──────────┼──────── ──┼──────── |
| bez modyfikatora│ + │ + │ + │ │ | 
| ───────────┼───────┼─────────┼──────────┼──────── ──┼──────── |
| prywatny │ + │ │ │ │ |
| ___________ | _______ | _________ | __________ | __________ | ________ |
 +: dostępne puste: niedostępne

(Zastrzeżenie: Nie jestem programistą Java, jestem programistą Perla. Perl nie ma formalnej ochrony, co może dlatego tak dobrze rozumiem problem :))

Prywatny

Jak mogłoby się wydawać, tylko klasa, w której jest zadeklarowana, może to zobaczyć.

Pakiet prywatny

Można go zobaczyć i wykorzystać tylko w pakiecie, w którym został zadeklarowany. Jest to ustawienie domyślne w Javie (które niektórzy uważają za błąd).

Chroniony

Pakiet Private + może być widoczny dla podklas lub członków pakietu.

Publiczny

Każdy to widzi.

Opublikowany

Widoczny poza kodem, który kontroluję. (Chociaż nie jest to składnia Java, jest to ważne w tej dyskusji).

C ++ definiuje dodatkowy poziom zwany „przyjacielem”, a im mniej o nim wiesz, tym lepiej.

Kiedy należy użyć Cały pomysł polega na enkapsulacji w celu ukrycia informacji. Na tyle, na ile to możliwe, chcesz ukryć szczegóły tego, jak coś się robi przed użytkownikami. Dlaczego? Ponieważ możesz je później zmienić i nie łamać niczyich kodów. Pozwala to optymalizować, refaktoryzować, przeprojektowywać i naprawiać błędy bez obawy, że ktoś używał właśnie zmodyfikowanego kodu.

Zatem podstawową zasadą jest, aby rzeczy były tak widoczne, jak powinny. Zacznij od prywatnego i dodaj więcej widoczności w razie potrzeby. Podaj do wiadomości publicznej tylko to, co jest absolutnie konieczne, aby użytkownik wiedział, każdy upubliczniony szczegół ogranicza twoją zdolność do przeprojektowania systemu.

Jeśli chcesz, aby użytkownicy mogli dostosowywać zachowania, zamiast upubliczniać elementy wewnętrzne, aby mogli je zastąpić, często lepszym pomysłem jest umieszczenie tych wnętrzności w obiekcie 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 dostosować bit „idź znaleźć informacje o tym dysku CD”, zamiast upubliczniać te metody, umieść całą tę funkcjonalność w swoim obiekcie i upublicznij tylko getter / setter obiektu . W ten sposób skąpstwo w ujawnianiu wnętrzności zachęca do dobrego składu i rozdzielenia obaw

Osobiście trzymam się tylko „prywatnego” i „publicznego”. Wiele języków OO właśnie to ma. „Chroniony” może być przydatny, ale to naprawdę oszustwo. Gdy interfejs jest bardziej niż prywatny, jest poza twoją kontrolą i musisz szukać kodu innej osoby, aby znaleźć zastosowania.

Właśnie tutaj pojawia się idea „opublikowania”. Zmiana interfejsu (refaktoryzacja) wymaga znalezienia całego kodu, który go używa, i zmiany również. 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 firmowym, który jest tylko do użytku wewnętrznego, nie ma znaczenia, czy interfejs jest publiczny. Możesz pobrać cały kod z repozytorium korporacyjnego. Ale jeśli interfejs zostanie „opublikowany”, jeśli kod korzysta z niego poza twoją kontrolą, oznacza to, że nie masz pewności. Musisz obsługiwać ten interfejs lub ryzykować łamanie kodu. Nawet chronione interfejsy można uznać za opublikowane (dlatego nie „

Wiele języków uważa, że ​​hierarchiczny charakter publicznego / chronionego / prywatnego jest zbyt ograniczający i niezgodny z rzeczywistością. W tym celu istnieje koncepcja klasy cech , ale to kolejny program.

Oto lepsza wersja tabeli, która zawiera również kolumnę dla modułów.

Objaśnienia

• Członek prywatny ( i) jest dostępny tylko w tej samej klasie, co został zadeklarowany.

• Element bez modyfikatora dostępu ( j) jest dostępny tylko w ramach klas w tym samym pakiecie.

• Chroniony członek ( k) jest dostępne we wszystkich klasach w tym samym opakowaniu i wewnątrz podklasy w innych pakietach.

• Członek publiczny ( l) jest dostępny dla wszystkich klas (chyba że rezyduje w module , który nie eksportuje pakietu, w którym jest zadeklarowany).

Który modyfikator wybrać?

Modyfikatory dostępu to narzędzie, które pomaga zapobiegać przypadkowemu zerwaniu enkapsulacji ^(*) . Zadaj sobie pytanie, czy chcesz, aby członek był czymś wewnętrznym dla klasy, pakietu, hierarchii klas, czy też nie jest wewnętrznym, i odpowiednio wybierz poziom dostępu.

Przykłady:

• Pole long internalCounterpowinno być prawdopodobnie prywatne, ponieważ jest zmienne i zawiera szczegóły implementacji.
• Klasa, która powinna być tworzona tylko w klasie fabrycznej (w tym samym pakiecie) powinna mieć konstruktor ograniczony do pakietu, ponieważ nie powinno być możliwości wywołania jej bezpośrednio spoza pakietu.
• Należy zabezpieczyć wewnętrzną void beforeRender()metodę wywoływaną tuż przed renderowaniem i używaną jako hak w podklasach.
• void saveGame(File dst)Metoda, która jest wywoływana z kodu GUI powinno być publiczne.

^{(*) 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         |       ✔       |     ✘     |       ✘       |   ✘    
____________________________________________________________________

Łatwa zasada. Zacznij od zadeklarowania wszystkiego jako prywatnego. A następnie postęp w kierunku społeczeństwa w miarę potrzeb i uzasadnienia projektu.

Podczas eksponowania członkowie zadaj sobie pytanie, czy eksponujesz opcje reprezentacji czy abstrakcji. Pierwszym jest coś, czego chcesz uniknąć, ponieważ wprowadzi zbyt wiele zależności od rzeczywistej reprezentacji niż od jej obserwowalnego zachowania.

Zasadniczo staram się unikać zastępowania implementacji metod przez podklasowanie; zbyt łatwo jest zepsuć logikę. Zadeklaruj metody chronione abstrakcyjnie, jeśli chcesz je zastąpić.

Podczas nadpisywania użyj także adnotacji @Override, aby nie dopuścić do uszkodzenia elementów podczas refaktoryzacji.

To jest właściwie trochę bardziej skomplikowane niż zwykłe pokazy siatki. Siatka mówi ci, czy dostęp jest dozwolony, ale co dokładnie stanowi dostęp? Poziomy dostępu współdziałają również z zagnieżdżonymi klasami i dziedziczeniem w złożony sposób.

Wywoływany jest również „domyślny” dostęp (określony przez brak słowa kluczowego) pakietem-prywatnym . Wyjątek: w interfejsie żaden modyfikator nie oznacza publicznego dostępu; modyfikatory inne niż publiczne są zabronione. Stałe enum są zawsze publiczne.

Podsumowanie

Czy dostęp do członka z tym specyfikatorem dostępu jest dozwolony?

• Członek jest private : tylko jeśli element członkowski jest zdefiniowany w tej samej klasie co kod wywołujący.
• Członek jest pakietem prywatnym: tylko jeśli kod wywołujący znajduje się w członku, który natychmiast dołącza pakiet.
• Członek jest protected : ten sam pakiet lub element członkowski jest zdefiniowany w nadklasie klasy zawierającej kod wywołujący.
• Członek jest public: Tak.

Do jakich specyfikatorów dostępu mają zastosowanie

Zmienne lokalne i parametry formalne nie mogą uzyskać dostępu do specyfikatorów. Ponieważ są one z natury niedostępne na zewnątrz zgodnie z zasadami określania zakresu, są w rzeczywistości prywatne.

W przypadku klas w najwyższym zakresie publicdozwolone są tylko pakiety prywatne. Wybór ten projekt jest przypuszczalnie dlatego, protectedi privatebyłoby zbędne na poziomie pakietu (nie ma dziedziczenie pakietów).

Wszystkie specyfikatory dostępu są możliwe dla członków klasy (konstruktory, metody i statyczne funkcje członka, zagnieżdżone klasy).

Powiązane: Dostępność klas Java

Zamówienie

Specyfikatory dostępu można ściśle zamówić

publiczne> chronione> pakiet-prywatny> prywatny

co oznacza, że publiczapewnia największy dostęp,private . Wszelkie odniesienia możliwe dla członka prywatnego są również ważne dla członka-pakietu członka prywatnego; każde odwołanie do prywatnego członka pakietu jest ważne w chronionym elemencie i tak dalej. (Udzielanie dostępu chronionym członkom innym klasom w tym samym pakiecie uznano za błąd).

Notatki

• Metody klasy mają dostęp 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 klasę. (Porównaj ze Scalą, która obsługuje to za pomocą private[this].)
• Potrzebujesz dostępu do konstruktora, aby zbudować obiekt. Zatem jeśli wszystkie konstruktory są prywatne, klasę można zbudować tylko za pomocą kodu żyjącego w klasie (zwykle statyczne metody fabryczne lub inicjalizatory zmiennych statycznych). Podobnie jest w przypadku konstruktorów pakietów prywatnych lub chronionych.
  • Tylko posiadanie konstruktorów prywatnych oznacza również, że klasy nie można podklasować zewnętrznie, ponieważ Java wymaga, aby konstruktory podklasy domyślnie lub jawnie wywoływały konstruktor nadklasy. (Może jednak zawierać zagnieżdżoną klasę, która ją podklasuje).

Klasy wewnętrzne

Musisz także wziąć pod uwagę zakresy zagnieżdżone , takie jak klasy wewnętrzne. Przykładem złożoności jest to, że klasy wewnętrzne mają członków, którzy sami mogą przyjmować modyfikatory dostępu. Możesz więc mieć prywatną klasę wewnętrzną z członkiem publicznym; czy można uzyskać dostęp do członka? (Patrz poniżej.) Ogólna zasada polega na tym, aby spojrzeć na zakres i zastanowić się rekurencyjnie, czy można uzyskać dostęp do każdego poziomu.

Jest to jednak dość skomplikowane i szczegółowe informacje można znaleźć w specyfikacji języka Java . (Tak, w przeszłości występowały błędy kompilatora).

Aby poznać smak interakcji między nimi, rozważ ten przykład. Możliwe jest „wyciekanie” prywatnych klas wewnętrznych; jest to zwykle 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();
    }
}

Dane wyjściowe kompilatora:

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

Niektóre powiązane pytania:

• Java - dostępność metody w klasie private-package?

Jako zasada:

• private: zakres klasy.
• default(lub package-private): zakres pakietu.
• protected: package scope + child(jak pakiet, ale możemy go podklasować z różnych pakietów). Chroniony modyfikator zawsze utrzymuje relację „rodzic-dziecko”.
• public: wszędzie

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

• (D) irect (wywołaj z metody w tej samej klasie lub za pomocą składni „this”).
• (R) eference (wywołaj metodę przy użyciu odwołania do klasy lub za pomocą składni „kropkowej”).
• (I) dziedziczenie (poprzez podklasę).

wtedy mamy ten prosty stół:

+—-———————————————+————————————+———————————+
|                 |    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 skrócie

• public: dostępny zewsząd.
• protected: dostępne dla klas tego samego pakietu i podklas znajdujących się w dowolnym pakiecie.
• default (nie określono modyfikatora): dostępne dla klas tego samego pakietu.
• private: dostępne tylko w tej samej klasie.

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ą to zobaczyć. Ale jak? Oto przykład, który, mam nadzieję, wyjaśnia zamieszanie:

• Załóżmy, że mamy 2 klasy; Fatheri Sonkażdy w swoim własnym pakiecie:

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

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

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

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

  1. Wewnątrz klasy znajdującej się w tym samym pakiecie, w którym foo()zdefiniowano ( fatherpackage):

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

  2. Wewnątrz podklasy w bieżącej instancji za pomocą thislub super:

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

  3. W odniesieniu, którego typem jest ta sama klasa:

     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. Odwołanie, którego typ jest klasą nadrzędną i znajduje się w pakiecie, w którym foo()jest zdefiniowane ( fatherpackage) [Można to uwzględnić w kontekście nr. 1]:

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

• Następujące sytuacje są nieprawidłowe.

  1. W odniesieniu, którego typ jest klasą nadrzędną i znajduje się poza pakietem, w którym foo()zdefiniowano ( fatherpackage):

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

  2. Podklasa inna niż podklasa w pakiecie podklasy (podklasa dziedziczy chronionych członków od rodzica i czyni je prywatnymi dla podklas):

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

Prywatny

• Metody, zmienne i konstruktory

Dostęp do metod, zmiennych i konstruktorów, które zostały zadeklarowane jako prywatne, można uzyskać tylko w obrębie samej deklarowanej klasy.

• Klasa i interfejs

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

Uwaga

Do zmiennych, które zostały zadeklarowane jako prywatne, można uzyskać dostęp poza klasą, jeśli w klasie znajdują się publiczne metody pobierające. Dostęp do zmiennych, metod i konstruktorów, które zostały zadeklarowane jako chronione w nadklasie, mogą uzyskać dostęp tylko podklasy w innym pakiecie lub dowolnej klasie w pakiecie klasy chronionych elementów członkowskich.

Chroniony

• Klasa i interfejs

Modyfikatora chronionego dostępu nie można zastosować do klasy i interfejsów.

Metody, pola mogą być uznane za chronione, jednak metody i pola w interfejsie nie mogą być uznane za chronione.

Uwaga

Dostęp chroniony daje podklasie szansę na użycie metody pomocniczej lub zmiennej, jednocześnie uniemożliwiając klasie niepowiązanej próbę jej użycia.

Publiczny

Dostęp do klasy, metody, konstruktora, interfejsu itp. Zadeklarowanych jako publiczny można uzyskać z dowolnej innej klasy.

Dlatego do pól, metod, bloków zadeklarowanych w klasie publicznej można uzyskać dostęp z dowolnej klasy należącej do Wszechświata Java.

• Różne pakiety

Jednak jeśli klasa publiczna, do której próbujemy uzyskać dostęp, znajduje się w innym pakiecie, klasa publiczna nadal musi zostać zaimportowana.

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

Domyślnie - brak słowa kluczowego:

Domyślny modyfikator dostępu oznacza, że ​​nie deklarujemy jawnie modyfikatora dostępu dla klasy, pola, metody itp.

• W ramach tych samych pakietów

Zmienna lub metoda zadeklarowana bez modyfikatora kontroli dostępu jest dostępna dla dowolnej innej klasy w tym samym pakiecie. Pola w interfejsie są domyślnie publiczne statyczne końcowe, a metody w interfejsie są domyślnie publiczne.

Uwaga

Nie możemy przesłonić pól statycznych. Jeśli spróbujesz je przesłonić, nie pokazuje żadnego błędu, ale nie działa tak jak my.

Powiązane odpowiedzi

• Przesłanianie metod statycznych w Javie

Odnośniki do linków

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 zwykle sprowadzają się do „Zasady najmniejszej wiedzy”. Zezwalaj tylko na najmniejszą widoczność, która jest potrzebna.

Prywatne : Ograniczony dostęp tylko do klasy

Domyślnie (bez modyfikatora) : Ograniczony dostęp do klasy i pakietu

Chroniony : ograniczony dostęp do klasy, pakietu i podklas (zarówno w pakiecie wewnętrznym, jak i zewnętrznym)

Publiczny : dostępny dla klasy, pakietu (wszystkich) i podklas ... Krótko mówiąc, wszędzie.

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

Publiczny: jest w zasadzie tak prosty, jak można 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ć bezpośredni dostęp, 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żesz uzyskać dostępu do tej zmiennej poza pakietem.

Zabezpieczony: możesz uzyskać dostęp do zmiennych w tym samym pakiecie, a także do podklasy w dowolnym innym pakiecie. więc w zasadzie jest to domyślne + Dziedziczone zachowanie.

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

Prywatny: może być dostępny w tej samej klasie.

W metodach niestatycznych możesz uzyskać bezpośredni dostęp z powodu tego odwołania (także w konstruktorach), ale aby uzyskać dostęp w metodach statycznych, musisz utworzyć obiekt klasy.

Dostęp do modyfikatorów w Javie.

Modyfikatory dostępu Java są używane do zapewnienia kontroli dostępu w Javie.

1. Domyślnie:

Dostępne dla klas tylko 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
  }
}

Ten dostęp jest bardziej ograniczony niż publiczny i chroniony, ale mniej ograniczony niż prywatny.

2. Publiczny

Można uzyskać do niego dostęp z dowolnego miejsca. (Globalny dostęp)

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: Cześć

3. Prywatny

Dostępne tylko w tej samej klasie.

Jeśli spróbujesz uzyskać dostęp do prywatnych członków jednej klasy w innej, wygeneruje 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. Chroniony

Dostępne tylko dla klas w tym samym pakiecie i dla 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: Cześć

• publiczny - dostępny z dowolnego miejsca w aplikacji.

• domyślne - dostępne z pakietu.

• chroniony - dostępny z pakietu i podklas w innym pakiecie. także

• prywatny - dostępny tylko z jego klasy.

Widoczny na opakowaniu. Domyślny. Nie są wymagane żadne modyfikatory.

Widoczny tylko dla klasy ( prywatny ).

Widoczny dla świata ( publiczny ).

Widoczny dla pakietu i wszystkich podklas ( chroniony ).

Zmienne i metody mogą być deklarowane bez żadnych wywoływanych modyfikatorów. Przykłady domyślne:

String name = "john";

public int age(){
    return age;
}

Modyfikator dostępu prywatnego - prywatny:

Dostęp do metod, zmiennych i konstruktorów, które zostały zadeklarowane jako prywatne, można uzyskać tylko w obrębie samej deklarowanej klasy. Modyfikator dostępu prywatnego jest najbardziej restrykcyjnym poziomem dostępu. Klasa i interfejsy nie mogą być prywatne.

Do zmiennych, które zostały zadeklarowane jako prywatne, można uzyskać dostęp poza klasą, jeśli w klasie znajdują się publiczne metody pobierające.

Korzystanie z prywatnego modyfikatora jest głównym sposobem, w jaki obiekt hermetyzuje się i ukrywa dane przed światem zewnętrznym.

Przykłady:

Public class Details{

    private String name;

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

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

Modyfikator dostępu publicznego - publiczny:

Dostęp do klasy, metody, konstruktora, interfejsu itp. Zadeklarowanych jako publiczny można uzyskać z dowolnej innej klasy. Dlatego do pól, metod, bloków zadeklarowanych w klasie publicznej można uzyskać dostęp z dowolnej klasy należącej do wszechświata Java.

Jeśli jednak klasa publiczna, do której próbujemy uzyskać dostęp, znajduje się w innym pakiecie, 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(){

}

Modyfikator dostępu chronionego - chroniony:

Dostęp do zmiennych, metod i konstruktorów, które zostały zadeklarowane jako chronione w nadklasie, mogą uzyskać dostęp tylko podklasy w innym pakiecie lub dowolnej klasie w pakiecie klasy chronionych elementów członkowskich.

Modyfikatora chronionego dostępu nie można zastosować do klasy i interfejsów. Metody, pola mogą być uznane za chronione, jednak metody i pola w interfejsie nie mogą być uznane za chronione.

Dostęp chroniony daje podklasie szansę na użycie metody pomocniczej lub zmiennej, jednocześnie uniemożliwiając klasie niepowiązanej próbę jej użycia.

class Van{

    protected boolean speed(){

    }
}

class Car{
    boolean speed(){
    }

}

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

.... Protected: Chroniony modyfikator dostępu jest trochę trudny i można powiedzieć, że jest nadzbiorem domyślnego modyfikatora dostępu. Członkowie chronieni są tacy sami jak członkowie domyślni, jeśli chodzi o dostęp do tego samego pakietu. Różnica polega na tym, że chronione elementy są również dostępne dla podklas klasy, w której element jest zadeklarowany, i które znajdują się poza pakietem, w którym obecna jest klasa nadrzędna.

Ale ci chronieni członkowie są „dostępni poza pakietem tylko poprzez dziedziczenie”. tzn. możesz uzyskać dostęp do chronionego elementu klasy w jego podklasie znajdującej się w innym pakiecie bezpośrednio, tak jakby element był obecny w samej podklasie. Ale ten chroniony element członkowski nie będzie dostępny w podklasie poza pakietem przy użyciu odwołania do klasy nadrzędnej. …

Odpowiedź Davida zawiera znaczenie każdego modyfikatora dostępu. Jeśli chodzi o to, kiedy z nich korzystać, proponuję upublicznić wszystkie klasy i metody każdej klasy przeznaczone do użytku zewnętrznego (jego API) i wszystko inne jako prywatne.

Z czasem zrozumiesz, kiedy niektóre klasy powinny być prywatne i kiedy zadeklarować, że niektóre metody są chronione do użycia w podklasach.

Uwaga: To tylko uzupełnienie przyjętej odpowiedzi.

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

Z modyfikatorów dostępu Java :

Modyfikator dostępu Java określa, które klasy mogą uzyskać dostęp do danej klasy oraz jej pól, konstruktorów i metod. Modyfikatory dostępu można określić osobno dla klasy, jej konstruktorów, pól i metod. Modyfikatory dostępu Java są również czasami określane w mowie codziennej jako specyfikatory dostępu Java, ale prawidłowa nazwa to modyfikatory dostępu Java. Klasy, pola, konstruktory i metody mogą mieć jeden z czterech różnych modyfikatorów dostępu Java:

• Element listy
• prywatny
• default (pakiet)
• chroniony
• publiczny

Od kontrolowania dostępu do samouczków członków klasy :

Modyfikatory poziomu dostępu określają, czy inne klasy mogą używać określonego pola lub wywoływać określoną metodę. Istnieją dwa poziomy kontroli dostępu:

• Na najwyższym poziomie - publiczny lub pakiet-prywatny (bez wyraźnego modyfikatora).
• Na poziomie członka - publiczny, prywatny, chroniony lub pakiet-prywatny (bez wyraźnego modyfikatora).

Klasę można zadeklarować za pomocą modyfikatora public, w którym to przypadku klasa ta jest widoczna dla wszystkich klas na całym świecie. Jeśli klasa nie ma modyfikatora (wartość domyślna, znana również jako pakiet-prywatny), jest widoczna tylko w swoim własnym pakiecie

Poniższa tabela pokazuje dostęp do elementów dozwolony przez każdy 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 elementu członkowskiego określonego przez poziom dostępu. Jak widać, klasa zawsze ma dostęp do swoich członków. Druga kolumna wskazuje, czy klasy w tym samym pakiecie co klasa (niezależnie od ich pochodzenia) mają dostęp do członka. Trzecia kolumna wskazuje, czy podklasy klasy zadeklarowane poza tym pakietem mają dostęp do elementu członkowskiego. Czwarta kolumna wskazuje, czy wszystkie klasy mają dostęp do członka.

Poziomy dostępu wpływają na ciebie na dwa sposoby. Po pierwsze, gdy korzystasz z klas pochodzących z innego źródła, takich jak klasy na platformie Java, poziomy dostępu określają, którzy członkowie tych klas mogą korzystać z własnych klas. Po drugie, kiedy piszesz klasę, musisz zdecydować, jaki poziom dostępu powinna mieć każda zmienna członkowska i każda metoda w twojej klasie.

Publicznie chronione Domyślne i prywatne są modyfikatorami dostępu.

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

1. Klasa może być publiczna lub domyślna
2. Członkowie klasy mogą być publiczni, chronieni, domyślni lub prywatni.

Prywatne nie jest dostępne poza klasą Domyślne jest dostępne tylko w pakiecie. Chroniony w pakiecie, a także w dowolnej klasie, która go rozszerza. Publiczny jest otwarty dla wszystkich.

Zwykle zmienne składowe są zdefiniowane jako prywatne, ale metody składowe są publiczne.

Często zdawałem sobie sprawę, że zapamiętywanie podstawowych pojęć dowolnego języka jest możliwe dzięki tworzeniu analogii w świecie rzeczywistym. Oto moja analogia do zrozumienia modyfikatorów dostępu w Javie:

Załóżmy, że jesteś studentem na uniwersytecie i masz przyjaciela, który przyjeżdża cię odwiedzić w weekend. Załóżmy, że na środku kampusu znajduje się duża statua założyciela uniwersytetu.

• Kiedy zabierasz go do kampusu, pierwszą rzeczą, którą widzisz ty i twój przyjaciel, jest ta statua. Oznacza to, że każdy, kto chodzi po kampusie, może spojrzeć na posąg bez zgody uniwersytetu. To czyni posąg PUBLICZNYM .

• Następnie chcesz zabrać przyjaciela do akademika, ale w tym celu musisz zarejestrować go jako gościa. Oznacza to, że dostaje przepustkę dostępu (taką samą jak Twoja), aby dostać się do różnych budynków na terenie kampusu. Dzięki temu jego karta dostępu będzie ZABEZPIECZONA .

• Twój przyjaciel chce się zalogować do kampusu WiFi, ale nie ma żadnych danych uwierzytelniających. Jedynym sposobem, w jaki może uzyskać dostęp online, jest udostępnienie mu swojego loginu. (Pamiętaj, że każdy student, który wybiera się na uniwersytet, również posiada te dane logowania). To sprawi, że twoje dane logowania będą BEZ MODYFIKATORA .

• Wreszcie, twój przyjaciel chce przeczytać raport z postępów w semestrze, który jest opublikowany na stronie internetowej. Jednak każdy uczeń ma swój osobisty login, aby uzyskać dostęp do tej sekcji witryny kampusu. To sprawiłoby, że te poświadczenia byłyby PRYWATNE .

Mam nadzieję że to pomoże!

Kiedy 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ępne tylko w tej samej klasie, w której zostało zadeklarowane

Teraz pojawia się zamieszanie, jeśli chodzi o defaultiprotected

default-> Brak słowa kluczowego modyfikatora dostępu. Oznacza to, że jest dostępny wyłącznie w pakiecie klasy. Nigdzie poza tym pakietem nie można uzyskać do niego dostępu.

protected-> Nieco mniej rygorystycznie niż defaulti poza tymi samymi klasami pakietów, można do nich uzyskać dostęp przez podklasy spoza deklarowanego pakietu .

Dostęp Java modyfikuje, którego możesz użyć

Modyfikator dostępu mogą być stosowane do class, field^[O] , method. Spróbuj uzyskać dostęp, podklasę lub zastąpić to.

• Dostęp do fieldlub methodjest przezclass .
• Dziedzictwo. classModyfikator dostępu następcy (podklasy) może być dowolny. methodModyfikator dostępu następcy (zastępowania) powinien być taki sam lub go rozwinąć

Najwyższą klasą (zakres pierwszego poziomu) może być publici default. Nested class^[Informacje] może mieć dowolny z nich

package nie dotyczy hierarchii pakietów

Modyfikatory szybkiego dostępu

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

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

Wszyscy używamy metod i modyfikatorów elementów, takich jak prywatny, publiczny, ... ale zbyt mało programistów używa pakietów do logicznego organizowania kodu.

Na przykład: Możesz umieścić wrażliwe metody bezpieczeństwa w pakiecie „bezpieczeństwa”. Następnie umieść klasę publiczną, która uzyskuje dostęp do niektórych kodów związanych z bezpieczeństwem w tym pakiecie, ale zachowaj prywatność innych pakietów klas bezpieczeństwa . Dlatego inni programiści będą mogli korzystać z publicznie dostępnej klasy spoza tego pakietu (chyba że zmienią modyfikator). To nie jest funkcja bezpieczeństwa, ale poprowadzi użytkowanie.

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

Inną rzeczą jest to, że klasy, które są od siebie bardzo zależne, mogą skończyć w tym samym pakiecie i mogą zostać ostatecznie refaktoryzowane lub scalone, jeśli zależność jest zbyt silna.

Jeśli wręcz przeciwnie, ustawisz wszystko jako publiczne , nie będzie jasne, do czego powinien lub nie powinien mieć dostęp, co może prowadzić do napisania dużo javadoc (który nie wymusza niczego przez kompilator ...).

Poniższy schemat blokowy wyjaśnia, w jaki sposób członkowie danych klasy podstawowej są dziedziczeni, gdy tryb dostępu do klasy pochodnej jest prywatny .

Uwaga: Deklarowanie członków danych za pomocą prywatnego specyfikatora dostępu jest znane jako ukrywanie danych.

Źródło: Specyfikatory dostępu - prywatne, publiczne i chronione

Moje dwa centy :)

prywatny:

klasa -> klasa najwyższego poziomu nie może być prywatna. klasy wewnętrzne mogą być prywatne, dostępne z tej samej klasy.

zmienna instancji -> dostępna tylko w klasie. Nie można uzyskać dostępu poza klasą.

pakiet prywatny:

klasa -> klasa najwyższego poziomu może być prywatna. Może być dostępny tylko z tego samego pakietu. Nie z paczki podrzędnej, nie z paczki zewnętrznej.

zmienna instancji -> dostępna z tego samego pakietu. Nie z paczki podrzędnej, nie z paczki zewnętrznej.

chroniony:

klasa -> klasa najwyższego poziomu nie może być chroniona.

zmienna instancji -> Dostępne tylko w tym samym pakiecie lub sub-pakiecie. Można uzyskać dostęp tylko poza pakietem podczas rozszerzania klasy.

publiczny:

klasa -> dostępne z pakietu / subpackage / innego pakietu

zmienna instancji -> dostępna z pakietu / subpackage / innego pakietu

Oto szczegółowa odpowiedź

https://github.com/junto06/java-4-beginners/blob/master/basics/access-modifier.md

• publiczny

  Jeśli członek klasy jest zadeklarowany publicznie, można uzyskać do niego dostęp z dowolnego miejsca

• chroniony

  Jeśli członek klasy jest zadeklarowany z chronionym słowem kluczowym, można uzyskać do niego dostęp od tych samych członków klasy, spoza członków klasy w tym samym pakiecie i odziedziczonych członków klasy. Jeśli członek klasy jest chroniony, NIE będzie można uzyskać do niego dostępu z zewnętrznej klasy pakietu, chyba że odziedziczona klasa zewnętrzna, tj. Rozszerzy drugą nadklasę pakietu. Ale członek klasy chronionej jest zawsze dostępny dla tych samych klas pakietów, NIE ma znaczenia, czy ta sama klasa pakietów jest dziedziczona, ani NIE

• domyślna

  W Javie domyślnie NIE jest słowem kluczowym modyfikatora dostępu. Jeśli członek klasy zostanie zadeklarowany bez słowa kluczowego modyfikatora dostępu, w tym przypadku jest uważany za członka domyślnego. Domyślny element członkowski klasy jest zawsze dostępny dla tych samych członków klasy pakietowej. Ale zewnętrzny członek klasy pakietu NIE może uzyskać dostępu do domyślnych członków klasy, nawet jeśli klasy zewnętrzne są podklasami w przeciwieństwie do członków chronionych

• prywatny

  Jeśli członek klasy jest zadeklarowany z chronionym słowem kluczowym, wówczas w tym przypadku jest dostępny TYLKO dla tych samych członków klasy

Specyfikatory dostępu w Javie: Istnieją 4 specyfikatory dostępu w Javie, a mianowicie prywatny, pakiet-prywatny (domyślnie), chroniony i publiczny w kolejności rosnącej.

Prywatne : Jeśli opracowujesz jakąś klasę i chcesz, aby członek tej klasy nie był wystawiany poza tą klasą, powinieneś zadeklarować ją jako prywatną. członkowie prywatni są dostępni tylko w klasie, w której są zdefiniowani, tj. w klasie obejmującej. członkowie prywatni są dostępni na podstawie tego „odwołania”, a także w innych przypadkach klasy obejmującej tych członków, ale tylko w ramach definicji tej klasy.

Pakiet prywatny (domyślny) : ten specyfikator dostępu zapewni dostęp określony przez prywatny specyfikator dostępu oprócz dostępu opisanego poniżej.

Kiedy opracowujesz jakiś pakiet, a tym samym jakąś klasę (powiedzmy Class1), możesz użyć domyślnego (nie trzeba wyraźnie wymieniać) specyfikatora dostępu, aby udostępnić członka w klasie, innym klasom w (tym samym) pakiecie. W tych innych klasach (w tym samym pakiecie) możesz uzyskać dostęp do tych domyślnych członków na instancji Class1. Możesz również uzyskać dostęp do tych domyślnych członków w ramach podklas klasy Class1, powiedzmy Class2 (w tym przypadku lub w instancji Class1 lub w instancji Class2).

Zasadniczo w ramach tego samego pakietu można uzyskać dostęp do domyślnych członków na instancji klasy bezpośrednio lub na podstawie „this” w podklasach.

chroniony : ten specyfikator dostępu zapewni dostęp określony przez specyfikator dostępu prywatnego do pakietu oprócz dostępu opisanego poniżej.

Gdy opracowujesz jakiś pakiet, a tym samym pewną klasę (powiedzmy Class1) w nim, powinieneś użyć chronionego specyfikatora dostępu dla elementu danych w Class1, jeśli nie chcesz, aby dostęp do tego członka był poza pakietem (powiedzmy w pakiecie konsumenta pakiet, tj. klient korzystający z interfejsów API), ale chcesz zrobić wyjątek i zezwolić na dostęp do tego elementu tylko wtedy, gdy klient zapisuje klasę, powiedzmy, że klasa 2 rozszerza klasę 1. Ogólnie rzecz biorąc, chronieni członkowie będą dostępni pod tym „odwołaniem” w klasach pochodnych, tj. Klasie 2, a także w jawnych instancjach klasy 2.

Proszę zanotować:

1. Nie będziesz mieć dostępu do odziedziczonego chronionego członka klasy 1 w klasie 2, jeśli spróbujesz uzyskać do niego dostęp w jawnej instancji klasy 1, mimo że jest w nim dziedziczony.
2. Kiedy napiszesz inną klasę Class3 w tym samym / innym pakiecie, który rozszerza klasę2, chroniony członek z klasy1 będzie dostępny w tym odwołaniu, a także w jawnej instancji klasy3. Będzie to prawdą w przypadku dowolnej rozszerzonej hierarchii, tj. Chroniony element członkowski będzie nadal dostępny dla tego odwołania lub instancji klasy rozszerzonej. Zauważ, że w klasie 3, jeśli utworzysz instancję klasy 2, nie będziesz mieć dostępu do chronionego elementu z klasy 1, mimo że jest on dziedziczony.

Podsumowując, dostęp do chronionych elementów można uzyskać w innych pakietach, tylko jeśli jakaś klasa z tego innego pakietu rozszerzy klasę obejmującą ten chroniony element, a chroniony element jest dostępny na podstawie tego „odwołania” lub jawnych instancji klasy rozszerzonej, w ramach definicji rozszerzonej klasa.

public : ten specyfikator dostępu zapewni dostęp określony przez chroniony specyfikator dostępu oprócz dostępu opisanego poniżej.

Gdy opracowujesz jakiś pakiet, a tym samym pewną klasę (powiedzmy Class1), powinieneś użyć specyfikatora publicznego dostępu dla elementu danych w Class1, jeśli chcesz, aby ten element był dostępny w innych pakietach na instancji Class1 utworzonej w innej klasie innych pakiet. Zasadniczo tego specyfikatora dostępu należy używać, gdy zamierzasz udostępnić uczestnikowi danych świat bez żadnych warunków.