Perché Java non supporta l'ereditarietà privata / protetta come C ++? [chiuso]

Mentre eredita una classe in C ++, l'utente può specificare l'identificatore di accesso come,

class Base
{
    public int mem1;
    protected in mem2;
};

class Derived1 : **private** Base
{
    // mem1 will be private here.
    // mem2 will be private here.
};

class Derived2 : **protected** Base
{
    // mem1 will be protected here.
    // mem2 will be protected here.
};

class Derived2 : **public** Base
{
    // mem1 will be public here.
    // mem2 will be protected here.
};

Ma lo stesso non è possibile in Java, vale a dire che l'estensione in java è sempre come l'eredità "pubblica" in C ++.

Qualcuno potrebbe spiegare il motivo di questo?

java object-oriented inheritance

— Rumit Parakhiya
fonte

Non è necessario un motivo per omettere una funzione, è necessario un motivo (idealmente, molti buoni) per aggiungerlo.

Si può rispondere solo speculativamente, votando per chiudere.

— Jimmy Hoffa,

Risposte:

La maggior parte dei vantaggi offerti dall'eredità privata / protetta può essere facilmente raggiunta attraverso l'incapsulamento. Thomas Eding ha fornito alcuni buoni esempi di casi che potrebbero essere semplificati con l'aggiunta dell'eredità privata / protetta e, sebbene si tratti di casi validi, esistono soluzioni alternative che non richiedono eredità privata / protetta e sono più "idiomatiche" (in Java su meno).

Gli sviluppatori del linguaggio Java hanno evidentemente ritenuto che i costi in termini di complessità necessari per supportare l'eredità privata / protetta (inclusa l'ereditarietà multipla) fossero superiori ai benefici che avrebbe fornito.

— pswg
fonte

Vale la pena notare che in C ++ ci sono alcune importanti differenze tra eredità privata e inclusione come membro, ma ruotano attorno all'ordine di inizializzazione e eredità multipla e quindi non si traducono nel più semplice sistema di oggetti di Java.

— Jan Hudec,

-1: " Qualsiasi vantaggio offerto dall'eredità privata / protetta può essere facilmente raggiunto attraverso l'incapsulamento." Sbagliato. Concordo con " La maggior parte dei benefici ..."

— Thomas Eding,

@ThomasEding Puoi fare un esempio di qualcosa che può essere ottenuto attraverso l'eredità privata / protetta ma non attraverso l'incapsulamento (o almeno qualcosa che richiederebbe una buona dose di lavoro per realizzare con l'incapsulamento)? Onestamente non riesco a pensarne uno, ma sono aperto a essere convinto.

— pswg,

Spiacenti, mi dispiace per quello. Ecco alcuni esempi in C ++. (1) Supponi di voler considerare internamente la classe Bcome A( Beredita privatamente da A) in modo da poterla usare polimorficamente in qualche metodo. Con la composizione, questo può essere fatto, ma è molto più complicato. Qui dovresti creare una sottoclasse separata A'(probabilmente una classe interna) che implementa la funzionalità che usi. Dovresti anche delegare manualmente le modifiche alla Bclasse genitore ( Bfa A'amicizia, A'accetta un riferimento a B). Suppongo che questo non sia troppo difficile da fare, ma incorre in un pasticcio nel codice. (Cont)

— Thomas Eding,

... (2) Se si desidera Baccedere alle variabili protette A, l'ereditarietà privata è di nuovo più semplice da implementare rispetto alla composizione. Con la composizione, è possibile implementare in A'modo simile come sopra e / o aumentare l'accesso delle variabili protette. (3) Supponiamo di voler una singola variabile membro statica condivisa che è la stessa variabile esatta tra le istanze del modello. Una soluzione è ereditare privatamente da una classe base non basata su modelli che ha il membro statico. La composizione non può risolvere questo problema, sebbene altre tecniche potrebbero (come fare amicizia con un'altra classe con il membro).

— Thomas Eding,

Poiché Java non ha ereditarietà multiple e tutto deve essere (pubblicamente) ereditato Object, non ci sono luoghi in Java in cui l'ereditarietà privata o protetta produrrebbe un programma valido.

— Bart van Ingen Schenau
fonte