Devo sempre incapsulare interamente una struttura di dati interna?

Si prega di considerare questa classe:

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThings(){
        return things;
    }

}

Questa classe espone l'array che utilizza per archiviare i dati, a qualsiasi codice client interessato.

L'ho fatto in un'app a cui sto lavorando. Avevo una ChordProgressionclasse che memorizza una sequenza di Chords (e fa alcune altre cose). Aveva un Chord[] getChords()metodo che restituiva la matrice di accordi. Quando la struttura dei dati ha dovuto cambiare (da un array ad un ArrayList), tutto il codice client si è rotto.

Questo mi ha fatto pensare: forse il seguente approccio è migliore:

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThing(int index){
        return things[index];
    }

    public int getDataSize(){
        return things.length;
    }

    public void setThing(int index, Thing thing){
        things[index] = thing;
    }

}

Invece di esporre la stessa struttura di dati, tutte le operazioni offerte dalla struttura di dati sono ora offerte direttamente dalla classe che la racchiude, usando metodi pubblici che delegano alla struttura di dati.

Quando la struttura dei dati cambia, solo questi metodi devono cambiare, ma dopo lo fanno, tutto il codice client funziona ancora.

Si noti che le raccolte più complesse degli array potrebbero richiedere alla classe che lo racchiude di implementare anche più di tre metodi solo per accedere alla struttura interna dei dati.

Questo approccio è comune? Cosa ne pensi di questo? Quali aspetti negativi ha altro? È ragionevole che la classe che racchiude implementi almeno tre metodi pubblici solo per delegare alla struttura di dati interna?

Codice come:

   public Thing[] getThings(){
        return things;
    }

Non ha molto senso, dal momento che il tuo metodo di accesso non sta facendo altro che restituire direttamente la struttura interna dei dati. Potresti anche dichiarare Thing[] thingsdi esserlo public. L'idea alla base di un metodo di accesso è quella di creare un'interfaccia che isola i client dalle modifiche interne e impedisce loro di manipolare la struttura dei dati effettiva, tranne nei modi discreti consentiti dall'interfaccia. Come hai scoperto quando si è rotto tutto il codice client, il tuo metodo di accesso non ha funzionato, è solo un codice sprecato. Penso che molti programmatori tendano a scrivere codice in questo modo perché hanno imparato da qualche parte che tutto deve essere incapsulato con metodi di accesso - ma questo è per i motivi che ho spiegato. Farlo solo per "seguire il modulo" quando il metodo di accesso non serve a nessuno scopo è solo rumore.

Consiglio vivamente la soluzione proposta, che raggiunge alcuni dei più importanti obiettivi dell'incapsulamento: offrire ai clienti un'interfaccia solida e discreta che li isola dai dettagli di implementazione interna della classe e non consente loro di toccare la struttura interna dei dati aspettarti nei modi che ritieni appropriati - "la legge del privilegio meno necessario". Se guardi ai grandi framework OOP popolari, come CLR, STL, VCL, il modello che hai proposto è diffuso, proprio per questo motivo.

Dovresti sempre farlo? Non necessariamente. Ad esempio, se hai classi di aiuto o di amicizia che sono essenzialmente un componente della tua classe lavoratrice principale e non sono "front side", non è necessario - è un eccesso che aggiungerà molto codice non necessario. E in quel caso, non userei affatto un metodo di accesso - è insensato, come spiegato. Dichiara semplicemente la struttura dei dati in un modo che è limitato solo alla classe principale che la utilizza - la maggior parte delle lingue supporta i modi per farlo - friendo dichiarandola nello stesso file della classe lavoratrice principale, ecc.

L'unico aspetto negativo che posso vedere nella tua proposta è che è più lavoro da codificare (e ora dovrai ricodificare le tue classi di consumatori - ma devi / dovresti farlo comunque.) Ma questo non è davvero un aspetto negativo - devi farlo nel modo giusto, e talvolta ci vuole più lavoro.

Una delle cose che rende buono un buon programmatore è che sanno quando vale il lavoro extra e quando non lo è. A lungo termine, mettere gli extra ora ripagherà con grandi dividendi in futuro - se non su questo progetto, poi su altri. Impara a programmare nel modo giusto e usa la tua testa al riguardo, non solo seguire roboticamente i moduli prescritti.

Si noti che le raccolte più complesse degli array potrebbero richiedere alla classe che lo racchiude di implementare anche più di tre metodi solo per accedere alla struttura interna dei dati.

Se stai esponendo un'intera struttura di dati attraverso una classe contenente, IMO devi pensare al motivo per cui quella classe è incapsulata, se non è semplicemente fornire un'interfaccia più sicura - una "classe wrapper". Stai dicendo che la classe contenente non esiste a tale scopo - quindi forse c'è qualcosa che non va nel tuo design. Valuta di suddividere le tue classi in moduli più discreti e stratificarli.

Una classe dovrebbe avere uno scopo chiaro e discreto e fornire un'interfaccia per supportare tale funzionalità - non di più. Potresti provare a raggruppare cose che non appartengono. Quando lo fai, le cose si rompono ogni volta che devi attuare un cambiamento. Più piccole e discrete sono le tue lezioni, più facile è cambiare le cose: pensa a LEGO.

Hai chiesto: dovrei sempre incapsulare interamente una struttura di dati interna?

Risposta breve: Sì, il più delle volte ma non sempre .

Risposta lunga: Penso che le lezioni seguano le seguenti categorie:

1. Classi che incapsulano dati semplici. Esempio: punto 2D. È facile creare funzioni pubbliche che offrano la possibilità di ottenere / impostare le coordinate X e Y ma è possibile nascondere facilmente i dati interni senza troppi problemi. Per tali classi, non è necessario esporre i dettagli della struttura dei dati interni.

2. Classi contenitore che incapsulano raccolte. STL ha le classiche classi di contenitori. Considero std::stringe anche std::wstringtra quelli. Essi forniscono una ricca interfaccia per affrontare le astrazioni, ma std::vector, std::stringe std::wstringanche fornire la possibilità di ottenere l'accesso ai dati grezzi. Non avrei fretta di chiamarle classi mal progettate. Non conosco la giustificazione per queste classi che espongono i loro dati grezzi. Tuttavia, nel mio lavoro, ho trovato necessario esporre i dati grezzi quando ho a che fare con milioni di nodi mesh e dati su quei nodi mesh per motivi di prestazioni.

   L'importante di esporre la struttura interna di una classe è che devi pensare a lungo prima di dare un segnale verde. Se l'interfaccia è interna a un progetto, sarà costoso cambiarlo in futuro, ma non impossibile. Se l'interfaccia è esterna al progetto (come quando si sta sviluppando una libreria che verrà utilizzata da altri sviluppatori di applicazioni), potrebbe essere impossibile cambiare l'interfaccia senza perdere i client.

3. Classi che sono per lo più funzionali in natura. Esempi: std::istream, std::ostream, iteratori dei contenitori STL. È assolutamente sciocco esporre i dettagli interni di queste classi.

4. Classi ibride. Queste sono classi che incapsulano alcune strutture di dati ma forniscono anche funzionalità algoritmiche. Personalmente, penso che questi siano il risultato di un design mal pensato. Tuttavia, se li trovi, devi decidere se ha senso esporre i loro dati interni caso per caso.

In conclusione: l'unica volta che ho trovato necessario esporre la struttura interna dei dati di una classe è quando è diventato un collo di bottiglia delle prestazioni.

Invece di restituire direttamente i dati grezzi, prova qualcosa del genere

class ClassA {
  private Things[] things;
  ...
  public Things[] asArray() { return things; }
  public List<Thing> asList() { ... }
  ...
}

Quindi, stai essenzialmente fornendo una collezione personalizzata che presenta qualunque faccia al mondo sia desiderata. Nella tua nuova implementazione quindi,

class ClassA {
  private List<Thing> things;
  ...
  public Things[] asArray() { return things.asArray(); }
  public List<Thing> asList() { return things; }
  ...
}

Ora hai l'incapsulamento corretto, nascondi i dettagli di implementazione e offri la retrocompatibilità (a un costo).

Dovresti usare le interfacce per quelle cose. Non sarebbe d'aiuto nel tuo caso, poiché l'array Java non implementa quelle interfacce, ma dovresti farlo d'ora in poi:

class ClassA{

    public ClassA(){
        things = new ArrayList<Thing>();
    }

    private List<Thing> things; // stores data

    // stuff omitted

    public List<Thing> getThings(){
        return things;
    }

}

In questo modo è possibile passare ArrayLista LinkedListqualsiasi altra cosa e non si romperà alcun codice poiché probabilmente verranno implementate tutte le raccolte Java (oltre alle matrici) che hanno (pseudo?) Accesso casuale List.

Puoi anche utilizzare Collection, che offrono meno metodi rispetto a Listma possono supportare raccolte senza accesso casuale o Iterableche possono persino supportare flussi ma non offrono molto in termini di metodi di accesso ...

Questo è abbastanza comune per nascondere la struttura dei dati interni al di fuori del mondo. A volte è eccessivo soprattutto in DTO. Lo consiglio per il modello di dominio. Se è necessario esporre, restituisci la copia immutabile. Insieme a questo suggerisco di creare un'interfaccia con questi metodi come get, set, remove etc.