Dlaczego klasa nie może być zdefiniowana jako chroniona?

Jak wiesz domyślnie jest dla dostępu na poziomie pakietu, a protected jest dla poziomu pakietu oraz klas niepakowanych, ale które rozszerza tę klasę (należy zauważyć, że możesz rozszerzyć klasę tylko wtedy, gdy jest widoczna!). Ujmijmy to tak:

• chroniona klasa najwyższego poziomu będzie widoczna dla klas w pakiecie.
• Teraz uwidocznienie go poza pakietem (podklasami) jest nieco mylące i trudne. Które klasy powinny być dopuszczone do dziedziczenia naszej chronionej klasy?
• jeśli wszystkie klasy mogą mieć podklasę, będzie ona podobna do public access specifier.
• If none then it is similar to default.

Ponieważ nie ma sposobu na ograniczenie podklasowania tej klasy przez kilka klas (nie możemy ograniczyć dziedziczenia klasy przez kilka klas ze wszystkich dostępnych klas w pakiecie/poza pakietem), nie ma zastosowania specyfików chronionego dostępu dla klas najwyższego poziomu. Dlatego nie jest to dozwolone.

public class A
{
    protected class B
    {
    }
}

Zdefiniowanie chronionego pola sprawia, że jest ono dostępne zarówno wewnątrz pakietu, jak i poza nim tylko poprzez dziedziczenie (tylko wewnątrz klasy potomnej).

Więc jeśli możemy stworzyć klasę chronioną, to możemy uzyskać dostęp do niej wewnątrz pakietu bardzo łatwo, ale aby uzyskać dostęp do tej klasy poza pakietem, najpierw musimy rozszerzyć encję, w której ta klasa jest zdefiniowana, która jest jej pakietem.

A ponieważ pakiet nie może być rozszerzony (może być importowany), definiowanie Klasa chroniona ponownie uczyni ją package-private, co jest podobne do zdefiniowania jej jako domyślnej, co już możemy zrobić. W związku z tym nie ma żadnej korzyści z definiowania klasy prywatnej, to tylko sprawi, że rzeczy będą niejednoznaczne.

Aby uzyskać więcej informacji przeczytaj Dlaczego zewnętrzna Klasa Java nie może być prywatna lub chroniona

Z 4 modyfikatorów dostępu "public, private, protected i default" klasa może mieć tylko modyfikator public i default.

Jeśli masz klasę publiczną, możesz jej używać wszędzie tam, gdzie chcesz, co jest bardzo proste. Możesz zaimportować go do dowolnego pakietu i zacząć z niego korzystać.

Ale jeśli masz klasę bez modyfikatora/domyślnego, nie możesz nawet zaimportować jej do innego pakietu. Na przykład masz klasę: as DefaultClass.java

package home;
class DefaultClass{
..
}

I kolejna klasa jako TestingIt.java w innym pakiecie.

package office;
import home.

W momencie, gdy próbujesz zaimportować do domu.DefaultClass w powyższym kodzie zdasz sobie sprawę, że nasza DefaultClass nie może być importowana. Nie jest widoczny dla paczki poza domem. Nie możemy zaimportować go w tym TestingIt.plik java. Dlaczego nie? ponieważ default = ogranicza się do własnego pakietu.

A teraz przechodząc do pytania " dlaczego klasa nie może mieć modyfikatora protected access?" Myślę, że to prawdopodobnie dlatego, że nie byłoby inaczej niż domyślne / nie Klasa modyfikatorów. Nawet jeśli "Klasa chroniona "byłaby możliwa, nie można by zaimportować jej do innego pakietu, tak jak"Klasa domyślna/bez modyfikatora".

Możesz użyć ich w tym samym pakiecie, ale po zaimportowaniu oba będą działać dokładnie tak samo w tym samym pakiecie. Stąd, jeśli chodzi o modyfikatory dostępu dla klas, zarówno protected, jak i default są takie same.

@Nikita Rybak odpowiedź ma dobre punkty, ale brak szczegółów, nie mogę po prostu dostać pomysł bez głębokiego myślenia siebie, poniżej jest to, co myślałem i teraz powinienem całkowicie zrozumieć powód.

Cztery modyfikatory dostępu, zakładają, że pierwszy poziom jest publiczny, a czwarty jest prywatny(na podstawie tej tabeli w sekwencji). Pierwszą rzeczą, którą powinniśmy wiedzieć, jest to, dlaczego klasa nie może być zdefiniowana jako prywatna na najwyższym poziomie.

Więc jeśli "private class foo" (prywatny członek zdefiniowany, tzn. klasa sama w sobie jest członkiem) allow, co to jest zewnętrzny (który zawiera członka)? Zakres plików ? Nie, zewnętrzny plik jest bezcelowy, ponieważ nawet wiele klas w jednym pliku będzie kompilowanych do oddzielnych plików klas. więc zewnętrzna jest paczka. Ale domyślny modyfikator dostępu trzeciego poziomu oznacza już " pakiet-prywatny ". Tak więc modyfikator dostępu prywatnego czwartego poziomu nie będzie używany/dozwolony.

Ale zagnieżdżona Klasa prywatna jest allow, ponieważ bezpośrednie outer is class, not package, np. :

class PrivateNestedMain {
    private static class Inner {
        public static void main(String[] args) {
            System.out.println("Hello from Inner!");
        }
    }
}

A co jeśli" protected class foo " pozwoli ? protected main characteristics jest podklasą, więc zewnętrzny(pakiet) powinien(ze względu na aktualny zakres, ale nadal jest opcjonalny) dostarczać styl podklasy , tj. sub-package, lub package A extends package B, ale nic takiego nie wiemy. Tak więc protected nie może używać pełnego potencjału (główny zakres jest szeroki na podklasę) na najwyższym poziomie, którego zewnętrznym jest pakiet( tzn. nie ma takiego pakietu), ale protected może używać pełny potencjał w klasie zagnieżdżonej, której zewnętrzna jest klasa(tzn. może być podklasą):

class ProtectedNestedMain {
    protected static class Inner {
        public static void main(String[] args) {
            System.out.println("Hello from Inner!");
        }
    }
}

Zauważ, że wyżej powiedziane "nie można wykorzystać pełnego potencjału" z powodu tego, że nie można dotrzeć do podklasy tylko dlatego, że nie ma zewnętrznej podklasy, to znaczy faktycznie chronione mogą być dozwolone, jest tylko kwestią wyboru, aby uniknąć powielania zadania pakietu-prywatnego, jeśli zewnętrzny nie jest podklasowalny , patrz poniżej.

Moje zagmatwanie spowodowane jest głównie słynnym stołem w https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html : {]}

Jeśli 1. poziom(publiczny) i 3. poziom (pakiet-prywatny) dozwolone, w jaki sposób między 2. poziom (chroniony) nie jest dozwolone ?

Podklasa wsparcia publicznego tak łatwa do wprowadzenia w błąd. Prawidłowy sposób odczytu tej tabeli to

Publiczna podklasa wsparcia, jeśli zewnętrzna ma funkcję podklasy.

To samo dotyczy pacakage-private, pacakage-private nie obsługuje podklasy ( N w komórce) nie oznacza, że podklasa concept apply in outer.

Oznacza to, że powinniśmy zignorować kolumnę Subclass, Jeśli funkcja subclass nie jest dostępna w outer:

Jak teraz widzimy, zarówno protected, jak i package-private są teraz tym samym poziomem (Y-Y-N), nie ma już więcej wątpliwości, dlaczego pomiędzy poziomami nie są dozwolone. Ogólnie, Java pick only package-private over protected to avoid mylące (to tylko kwestia wyboru , ale chroniona główna charakterystyka jest podklasą, więc pakiet-prywatny jest nadrzędny), a wynik, tylko 2 modyfikatory dostępu dozwolone na najwyższym poziomie:

Na najwyższym poziomie-public, lub package-private (bez jawnego modyfikatora).

Protected nie jest podobne do public. Protected ma zarówno dostęp na poziomie pakietu, jak i dostęp poza pakietami tylko przez dziedziczenie..Jeśli Klasa say a poza pakietem dziedziczy klasę z innego pakietu (z metodą protected by using INHERITANCE), może uzyskać dostęp do metod tej klasy B, która ma metody protected, ale podklasy pochodzące z tej klasy, tzn. A nie mogą uzyskać dostępu do chronionych metod..odwrotnie dzieje się z publicznością..

Przykład:

package 2;
class B
{
protected void method1()
{
}
}
package 1;
import 2.B;
class A extends B
{
//can access protected method
}
class C extends A
{
//can't access the protected method
}

Zachowanie "protected" = zachowanie "default" + "użyj go w dowolnej podklasie w dowolnym pakiecie".

W każdym razie mamy domyślny modyfikator dostępu dla klasy, jedyną zaletą, jaką możemy uzyskać z modyfikatora dostępu chronionego jest:- używając go w dowolnym pakiecie poprzez podklasowanie. Ale dla podklasy, widoczność nadrzędnej "chronionej" klasy będzie prywatna. Więc nie ma do niego dostępu. Zasadniczo, jeśli masz chronioną klasę najwyższego poziomu, żadna klasa zewnętrzna nie może uzyskać dostępu przez podklasowanie jej. Tak chronione na najwyższym poziomie klasa jest bez znaczenia.

Protected : widoczny tylko na poziomie pakietu*.

Class is defined protected ---> nie można go rozszerzyć z zewnętrznego pakietu (niewidoczny).

A jeśli nie można go rozszerzyć, to nie ma sensu trzymać go jako chronionego , ponieważ wtedy będzie todomyślnym Dostęp, który jest dozwolony.

To samo dotyczy prywatnych zdefiniowanych klas.

Notatka: można zdefiniować klasy zagnieżdżone lub wewnętrzne protected or private .

* : zbadaj chronione słowo kluczowe, dla tej odpowiedzi zrobiłem zwięzły.

Odpowiedź od @Akash5288 nie miała dla mnie sensu:

Jeśli wszystkie klasy mogą mieć podklasę, będzie ona podobna do public access specifier.

Ponieważ nie ma sposobu na ograniczenie podklasowania tej klasy przez kilka klas (nie możemy ograniczyć dziedziczenia klasy przez kilka klas ze wszystkich dostępnych klas w pakiecie/poza pakietem), nie ma zastosowania specyfików chronionego dostępu dla klas najwyższego poziomu. Stąd nie jest dozwolone.

Można wtedy zastosować tę samą logikę do chronionych metod i zmiennych, są one również wtedy "podobne do publicznych". Wszystkie klasy spoza pakietu mogą rozszerzyć naszą klasę publiczną i używać jej chronionych metod. Dlaczego ograniczanie metod i zmiennych do rozszerzonych klas jest ok, ale ograniczanie całej klasy nie jest ok? "Podobny do publicznego" nie jest "taki sam jak publiczny". Moja interpretacja jest taka, że jest to całkowicie w porządku, aby pozwolić chronionej klasy, jak to jest w porządku, aby umożliwić chronione metody.

Odpowiedź "nie możesz rozszerzyć klasy, do której nie masz dostępu/nie widzisz" jest bardziej logiczna.

Sensowne jest to, że JVM jest napisany w C (Sun JVM) i C++(oracle JVM), więc podczas kompilacji będziemy tworzyć .pliki klas z naszego pliku java i jeśli zadeklarujemy klasę ze słowem kluczowym Protected, to JVM nie uzyska do niej dostępu.

Odpowiedź dlaczego Klasa protected nie będzie dostępna przez JVM jest taka, że ponieważ pola protected są dostępne w ramach tego samego pakietu lub dla innego pakietu tylko poprzez dziedziczenie, a JVM nie jest napisane w taki sposób, aby odziedziczy klasę. Mam nadzieję, że to zadowoli to pytanie:)

Podobnie, klasa najwyższego poziomu nie może być prywatna. Wyjaśnienie jak poniżej:

Więc co się stanie, jeśli zdefiniujemy klasę prywatną, ta klasa będzie dostępna tylko w encji, w której jest zdefiniowana, która w naszym przypadku jest jej pakietem?

Więc zdefiniowanie prywatnego dostępu do klasy sprawi, że będzie ona dostępna w tym samym pakiecie, co domyślne słowo kluczowe już dla nas robi, dlatego nie ma żadnej korzyści z zdefiniowanie klasy prywatnej spowoduje, że rzeczy będą niejednoznaczne.

protected means that the member can be accessed by any class in the same package 
and by sub classes even if they are in another packages.
example:
    package a;
    class parent{
     protected void p();
    }
    package b;
    import a.p;
    class child extends parent{
      //you can access method which is protected in the parent in the child 
    }
    class another extends child {
     //here you can not access the protected method 
    }