Dlaczego w Javie nie ma modyfikatora dostępu „tylko podklasy”?

W Javie dostępne są cztery modyfikatory dostępu do metod:

public - każda klasa może korzystać z tej metody.

protected - klasy w tym samym pakiecie i podklasy w dowolnym pakiecie mogą korzystać z tej metody.

private - tylko ta klasa może korzystać z tej metody.

no modifier („pakiet prywatny”) - tylko klasy w tym samym pakiecie mogą korzystać z tej metody.

Często zdarza się, że chcę mieć użyteczne metody w nadklasie, z których mogą korzystać wszystkie podklasy. Ale dostęp do tej metody nie miałby sensu dla innych klas iw pewnym sensie spowodowałoby to przerwanie enkapsulacji.

Muszę więc zadeklarować te użyteczne metody w nadklasie publiclub protected, co wystawia je wszystkim pozostałym klasom przynajmniej w pakiecie. Mimo że są przeznaczone wyłącznie do wykorzystania przez podklasy.

Czy istnieje powód, dla którego nie ma subclasses-onlymodyfikatora dostępu w Javie? Wydaje mi się to bardzo dziwne. Czy coś brakuje?

Również subclasses-onlymodyfikator dostępu byłby przydatny, gdy chcesz wystawiać zmienne tylko na podklasy. Co mi się często zdarza.

Ponieważ można emulować modyfikator tylko podklas, używając chronionego modyfikatora i wymuszając, że tylko klasa nadrzędna i jej podklasy znajdują się w tym samym pakiecie.

To rzeczywiście dobra praktyka, ponieważ pakiety nie tylko pomagają organizować duże projekty pod względem spójności, ale pokazują również, że klasy w tym samym pakiecie mogą mieć pewien poziom sprzężenia.

Java pierwotnie miała taki modyfikator. Został napisany, private protectedale usunięty w Javie 1.0.

Zakładam, że było to wezwanie do oceny, że dodatkowa złożoność nie była warta kosztów.

Każda funkcja językowa ma swój koszt: ucząc ją nowych programistów; w dokumentacji; implementując go w kompilatorze, JVM i narzędziach programistycznych; w uzasadnieniu poprawności programu; w ograniczaniu przyszłej ewolucji języka; i więcej. Funkcje językowe współdziałają ze sobą, potencjalnie z interakcjami N ² .

Jaki procent programistów Java przeczytał specyfikację języka Java i specyfikację VM? Założę się, że to niewielki procent, który przemawia za jeszcze prostszym językiem ze względu na zrozumiałość i inżynierię produktów, od których możemy polegać

Zaleta tej private protectedfunkcji była niewielka, ponieważ pakiet jest główną jednostką modułowości.

Kontrola dostępu może być wymyślona w wyniku relacji z wyimaginowanym programistą, który pracuje z twoją klasą nad metodami klasowymi i ich właściwościami ...

TY: Powiedz, że chcesz zrobić x, wywołujesz metodę doX .. DEV: Powiedz mi więcej ... jakie są argumenty?

To jest publiczne ...

TY: Wewnątrz doX dzwonię ... DEV: Zaraz, za dużo informacji, nie obchodzi mnie to. Chcę tylko wiedzieć, jak go używać. Powiedz mi coś innego.

To jest prywatne ...

TY: Podczas subklasy mam doX i doY wywołuję doI, co robi ... DEV: Tak, podklasę, powiedz mi więcej ...

To jest chronione ...

TY: Wyjeżdżam na wakacje za godzinę, nie będzie mnie przez następne 6 miesięcy. Szef mówi, że ten szczeniak jest twój! PA. DEV: Czekaj, jeszcze nie idź, powiedz mi wszystko ...

To jest pakiet.

TY: Metoda DOItWhen jest wywoływana tylko przez tę klasę i nie zmieniła się od dziesięciu lat. To ... DEV: Zaraz, do 50 minut. Następna nieruchomość i mów szybciej.

To jest chronione prywatnie ...

To już istnieje. Jest chroniony

Masz kontrolę nad tym, jakie klasy istnieją w pakiecie. Jeśli w pakiecie nie ma innej klasy, a dana zmienna lub metoda jest chroniona, jest to „tylko podklasa”.

To powiedziawszy, po raz kolejny masz kontrolę nad tym, jakie klasy istnieją w pakiecie. Możesz po prostu nie używać chronionych metod lub zmiennych.