Quando dovresti usare una classe privata / interna?

Per chiarire, quello che sto chiedendo è

public class A{
    private/*or public*/ B b;
}

vs.

public class A{
    private/*or public*/ class B{
        ....
    }
}

Posso sicuramente pensare ad alcuni motivi per usare l'uno o l'altro, ma quello che mi piacerebbe davvero vedere sono esempi convincenti che dimostrano che i pro ei contro non sono solo accademici.

In genere vengono utilizzati quando una classe è un dettaglio di implementazione interna di un'altra classe anziché una parte della sua interfaccia esterna. Li ho visti principalmente come classi di soli dati che rendono le strutture di dati interne più pulite in linguaggi che non hanno una sintassi separata per le strutture in stile c. Sono anche utili a volte per oggetti derivati ​​ad un metodo altamente personalizzati come gestori di eventi o thread di lavoro.

Supponiamo di costruire un albero, un elenco, un grafico e così via. Perché dovresti esporre i dettagli interni di un nodo o di una cella al mondo esterno?

Chiunque utilizzi un grafico o un elenco dovrebbe fare affidamento solo sulla sua interfaccia, non sulla sua implementazione, dal momento che potresti voler cambiarlo un giorno in futuro (ad esempio da un'implementazione basata su array a una basata su puntatore) e i client che utilizzano il tuo la struttura dei dati ( ognuno di essi ) dovrebbe modificare il proprio codice per adeguarlo alla nuova implementazione.

Invece, l'incapsulamento dell'implementazione di un nodo o di una cella in una classe interna privata ti dà la libertà di modificare l'implementazione ogni volta che è necessario, senza che i client siano costretti a modificare il loro codice di conseguenza, finché l'interfaccia della struttura dei dati rimane intatto.

Nascondere i dettagli dell'implementazione della struttura dei dati porta anche a vantaggi in termini di sicurezza, perché se si desidera distribuire la classe si renderà disponibile solo il file di interfaccia insieme al file di implementazione compilato e nessuno saprà se si stanno effettivamente utilizzando array o puntatori per la tua implementazione, proteggendo così la tua applicazione da un qualche tipo di sfruttamento o, almeno, conoscenza dovuta all'impossibilità di abusare o ispezionare il tuo codice. Oltre ai problemi pratici, non sottovalutare il fatto che in questi casi sia una soluzione estremamente elegante.

A mio avviso, è un poliziotto equo utilizzare le classi definite internamente per le classi che vengono utilizzate brevemente in una classe per consentire un'attività specifica.

Ad esempio, se è necessario associare un elenco di dati costituito da due classi non correlate:

public class UiLayer
{
    public BindLists(List<A> as, List<B> bs)
    {
        var list = as.ZipWith(bs, (x, y) => new LayerListItem { AnA = x, AB = y});
        // do stuff with your new list.
    }

    private class LayerListItem
    {
        public A AnA;
        public B AB;
    }
}

Se la tua classe interna viene utilizzata da un'altra classe, dovresti metterla a parte. Se la tua classe interna contiene qualche logica, dovresti metterla a parte.

Fondamentalmente, penso che siano fantastici per tappare buchi nei tuoi oggetti dati, ma sono difficili da mantenere se devono contenere effettivamente la logica, poiché dovrai sapere dove cercarli se devi cambiarli.

• Le classi interne in alcune lingue (ad esempio Java) hanno un legame con un oggetto della loro classe di contenimento e possono usare i loro membri senza qualificarli. Se disponibile, è più chiaro che reimplementarli utilizzando altre strutture linguistiche.

• Le classi nidificate in altre lingue (ad esempio C ++) non hanno tale legame. Stai semplicemente usando il controllo di scoping e accessibilità fornito dalla classe.

Evito le classi interne in Java perché lo scambio a caldo non funziona in presenza di classi interne. Lo odio perché odio davvero compromettere il codice per tali considerazioni, ma quei riavvi di Tomcat si sommano.

Uno degli usi per la classe interna statica privata è il modello Memo. Metti tutti i dati che devono essere ricordati in classe privata e li restituisci da una funzione come Oggetto. Nessuno al di fuori non può (senza riflessione, deserializzazione, ispezione della memoria ...) esaminarlo / modificarlo, ma può restituirlo alla tua classe e ripristinarne lo stato.

Un motivo per utilizzare una classe interna privata potrebbe essere perché un'API che stai utilizzando richiede l'ereditarietà di una classe particolare, ma non vuoi esportare la conoscenza di quella classe agli utenti della tua classe esterna. Per esempio:

// async_op.h -- someone else's api.
struct callback
{
    virtual ~callback(){}
    virtual void fire() = 0;
};

void do_my_async_op(callback *p);



// caller.cpp -- my api
class caller
{
private :
    struct caller_inner : callback
    {
        caller_inner(caller &self) : self_(self) {}
        void fire() { self_.do_callback(); }
        caller &self_;
    };

    void do_callback()
    {
        // Real callback
    }

    caller_inner inner_;

public :
    caller() : inner_(*this) {}

    void do_op()
    {
        do_my_async_op(&inner_);
    }
};

In questo, do_my_async_op richiede che gli venga passato un oggetto di tipo callback. Questo callback ha un firma della funzione membro pubblico utilizzata dall'API.

Quando do_op () viene chiamato da outer_class, utilizza un'istanza della classe interna privata che eredita dalla classe di richiamata richiesta anziché un puntatore a se stessa. La classe esterna ha un riferimento alla classe esterna al semplice scopo di deviare il callback nella classe esterna funzione membro privata do_callback .

Il vantaggio è che sei sicuro che nessun altro può chiamare la funzione pubblica "fire ()".

Secondo Jon Skeet in C # in Depth, l'uso di una classe nidificata era l'unico modo per implementare un singleton completamente pigro e sicuro per i thread (vedi Quinta versione) (fino a .NET 4).

Le classi private e interne vengono utilizzate per aumentare i livelli di incapsulamento e nascondere i dettagli di implementazione.

In C ++, oltre a una classe privata, lo stesso concetto può essere realizzato implementando lo spazio dei nomi anonimo di una classe cpp. Questo serve a nascondere / privatizzare un dettaglio di implementazione.

È la stessa idea di una classe interna o privata ma a un livello ancora maggiore di incapsulamento in quanto è completamente invisibile al di fuori dell'unità di compilazione del file. Nulla di ciò appare nel file di intestazione o è esternamente visibile nella dichiarazione della classe.