Perché non esiste un modificatore di accesso "solo sottoclassi" in Java?

16

In Java, ci sono quattro modificatori di accesso disponibili per i metodi:

public - qualsiasi classe può utilizzare questo metodo.

protected - le classi nello stesso pacchetto e le sottoclassi di qualsiasi pacchetto possono utilizzare questo metodo.

private - solo questa classe può utilizzare questo metodo.

no modifier ("pacchetto privato") - solo le classi nello stesso pacchetto possono usare questo metodo.

Quello che succede spesso è che voglio avere metodi utili in una superclasse, che tutte le sottoclassi possano usare. Ma non avrebbe senso per le altre classi accedere a questo metodo, e in un certo senso spezzerebbe l'incapsulamento.

Quindi devo dichiarare questi metodi utili nella superclasse publico protected, che li espone a tutte le altre classi almeno nel pacchetto. Anche se sono pensati per essere utilizzati solo dalle sottoclassi.

C'è un motivo per cui non esiste un subclasses-onlymodificatore di accesso in Java? Mi sembra molto strano. Mi sto perdendo qualcosa?

Inoltre, un subclasses-onlymodificatore di accesso sarebbe utile anche quando si desidera esporre le variabili solo alle sottoclassi. Il che per me succede molto.

— Aviv Cohn
fonte

10

Perché è possibile emulare solo le sottoclassi modificatore utilizzando il modificatore protetto e imponendo che solo la classe padre e le sue sottoclassi si trovino nello stesso pacchetto.

È davvero una buona pratica, perché i pacchetti non solo aiutano a organizzare grandi progetti in termini di coesione, ma mostrano anche che le classi nello stesso pacchetto potrebbero avere un certo livello di accoppiamento.

— Tércio de Almeida
fonte

15

"e imponendo che solo la classe genitore e le sue sottoclassi siano nello stesso pacchetto" - Ora, come si farebbe ?!

— JimmyB,

1

E quindi non è possibile utilizzare il modificatore di accesso solo pacchetto. E hai bisogno di una quantità stupida di pacchetti. Questa non è una soluzione pratica.

— user253751

13

Java originariamente aveva un tale modificatore. È stato scritto private protectedma rimosso in Java 1.0.

Presumo che fosse un appello di giudizio che la complessità extra non valeva il costo.

Ogni caratteristica linguistica ha un costo: nell'insegnarla a nuovi programmatori; nella documentazione; nella sua implementazione nel compilatore, JVM e strumenti di sviluppo; nel ragionamento sulla correttezza del programma; nel limitare l'evoluzione del linguaggio futuro; e altro ancora Le funzionalità del linguaggio interagiscono tra loro, potenzialmente con interazioni N ² .

Quale percentuale di programmatori Java ha letto le specifiche del linguaggio Java e le specifiche VM? Scommetto che è una piccola percentuale, che sostiene un linguaggio ancora più semplice per motivi di comprensibilità e ingegneria dei prodotti su cui possiamo contare

Il vantaggio della private protectedfunzionalità era ridotto poiché il pacchetto è l'unità principale della modularità.

— Jerry101
fonte

1

quindi c'era una versione Java prima della 1.0?

— Mark Yisri,

1

@MarkYisri Java aveva rilasci pubblici alfa e beta nel 1995 e un bel po 'di codice era scritto contro di loro.

— David Moles,

4

Il controllo degli accessi può essere pensato come il risultato di una copertura con uno sviluppatore immaginario che sta lavorando con la tua classe sui metodi e le proprietà della classe ...

TU: Dimmi che vuoi fare x, chiami il metodo doX .. DEV: Dimmi di più ... quali sono gli argomenti?

Questo è pubblico ...

YOU: All'interno di doX chiamo ... DEV: Whoa, troppe informazioni, non mi interessa. Voglio solo sapere come usarlo. Dimmi qualcos'altro.

Questo è privato ...

VOI: Durante la sottoclasse, ho doX e doY lo chiamano doIt che lo fa. DEV: Sì, lo farò sottoclasse, dimmi di più ...

Questo è protetto ...

VOI: tra un'ora partirò in vacanza, me ne andrò per i prossimi 6 mesi. Il capo dice che questo cucciolo è tuo! Ciao. DEV: Aspetta non andare ancora, dimmi tutto ...

Questo è un pacchetto.

TU: Il metodo doItWhen viene chiamato solo da questa classe e non è cambiato da dieci anni. It ... DEV: Whoa, siamo scesi a 50 minuti. Proprietà successiva e parla più velocemente.

Questo è protetto privato ...

— jmoreno
fonte

3

Questo esiste già. È protetto.

Hai il controllo su quali classi esistono all'interno del pacchetto. Se non ci sono altre classi nel pacchetto e una determinata variabile o metodo è protetto, è "solo sottoclassi".

Detto questo, ancora una volta, hai il controllo su quali classi esistono all'interno del pacchetto. Puoi scegliere di non usare solo i metodi o le variabili protetti.

3

A parte alcuni pacchetti di sistema riservati, non posso aggiungere una classe a nessun pacchetto, anche uno dei tuoi a cui non intendi che io aggiunga classi?

— David Moles,

@David IIRC sì, ma non ti permetterà di accedere ai campi del pacchetto da un altro JAR, quindi anche se lo metti nello stesso pacchetto, se è in un altro JAR non puoi accedervi. Tuttavia, se ti riferisci allo stesso JAR, quindi sì, puoi accedervi, ma se sei in grado di modificare il JAR in questione, puoi modificare altrettanto facilmente il modificatore di accesso.

— Pokechu22,

1

@ Pokechu22 Penso che devi sigillare affermativamente il JAR per ottenere quella protezione, ma un buon punto.

— David Moles,