Perché le raccolte Java sono state implementate con "metodi opzionali" nell'interfaccia?

Durante la mia prima implementazione che ha esteso il framework di raccolta Java, sono rimasto piuttosto sorpreso nel vedere che l'interfaccia di raccolta contiene metodi dichiarati opzionali. L'implementatore dovrebbe generare UnsupportedOperationExceptions se non supportato. Questo mi ha subito colpito come una cattiva scelta di progettazione API.

Dopo aver letto gran parte dell'eccellente libro "L'efficace Java" di Joshua Bloch, e dopo aver appreso che potrebbe essere responsabile di queste decisioni, non sembrava gelare con i principi sposati nel libro. Penserei di dichiarare due interfacce: Collection e MutableCollection che estende Collection con i metodi "opzionali" avrebbe portato a un codice client molto più gestibile.

C'è un eccellente riassunto dei problemi qui .

C'è stata una buona ragione per cui sono stati scelti metodi opzionali anziché l'implementazione delle due interfacce?

Le FAQ forniscono la risposta. In breve, hanno visto una potenziale esplosione combinatoria di interfacce necessarie con vista modificabile, non modificabile, solo cancellazione, solo aggiunta, lunghezza fissa, immutabile (per il threading) e così via per ogni possibile serie di metodi di opzione implementati.

Mi sembra che Interface Segregation Principlenon fosse così esplorato allora come lo è ora; quel modo di fare le cose (cioè la tua interfaccia include tutte le operazioni possibili e hai metodi "degenerati" che generano eccezioni per quelli che non ti servono) era popolare prima che SOLID e ISP diventassero lo standard di fatto per il codice di qualità.

Mentre alcune persone potrebbero detestare i "metodi opzionali", in molti casi possono offrire una semantica migliore rispetto alle interfacce altamente segregate. Tra le altre cose, consentono le possibilità che un oggetto possa acquisire abilità o caratteristiche durante la sua vita, o che un oggetto (specialmente un oggetto wrapper) potrebbe non sapere quando è costruito quali abilità esatte dovrebbe riferire.

Mentre difficilmente chiamerò le classi di raccolta Java paragoni di buon design, suggerirei che un buon framework di raccolte dovrebbe includere alla sua base un gran numero di metodi opzionali insieme a modi di chiedere a una collezione le sue caratteristiche e abilità . Un tale design consentirà di utilizzare una singola classe wrapper con una grande varietà di collezioni senza oscurare accidentalmente le capacità che la collezione sottostante potrebbe possedere. Se i metodi non fossero facoltativi, sarebbe necessario disporre di una classe wrapper diversa per ogni combinazione di funzionalità che le raccolte potrebbero supportare, altrimenti alcune wrapper potrebbero essere inutilizzabili in alcune situazioni.

Ad esempio, se una raccolta supporta la scrittura di un elemento per indice o l'aggiunta di elementi alla fine, ma non supporta l'inserimento di elementi nel mezzo, il codice che desidera incapsularlo in un wrapper che registra tutte le azioni eseguite su di esso richiederebbe una versione del wrapper di logging che prevedeva la combinazione esatta di abilità supportate, o se nessuna fosse disponibile avrebbe dovuto usare un wrapper che supportava append o write-by-index ma non entrambi. Se, tuttavia, un'interfaccia di raccolta unificata forniva tutti e tre i metodi come "opzionali", ma includeva quindi metodi per indicare quale dei metodi opzionali sarebbe utilizzabile, una singola classe wrapper poteva gestire raccolte che implementano qualsiasi combinazione di caratteristiche. Quando viene chiesto quali funzioni supporta, un wrapper può semplicemente segnalare qualsiasi supporto della raccolta incapsulata.

Si noti che l'esistenza di "abilità opzionali" può in alcuni casi consentire alle raccolte aggregate di implementare determinate funzioni in modi molto più efficienti di quanto sarebbe possibile se le abilità fossero definite dall'esistenza di implementazioni. Ad esempio, supponiamo concatenateche sia stato usato un metodo per formare una raccolta composita da altri due, il primo dei quali era una ArrayList con 1.000.000 di elementi e l'ultimo dei quali era una raccolta di venti elementi che poteva essere ripetuta dall'inizio. Se fosse richiesta la raccolta composita per il 1.000.013 ° elemento (indice 1.000.012), si potrebbe chiedere all'ArrayList quanti elementi conteneva (cioè 1.000.000), sottrarre quello dall'indice richiesto (producendo 12), leggere e saltare dodici elementi dal secondo raccolta e quindi restituisce l'elemento successivo.

In una situazione del genere, anche se la raccolta composita non avrebbe un modo istantaneo di restituire un articolo per indice, chiedere alla raccolta composita per il 1.000.013 ° articolo sarebbe comunque molto più veloce che leggere 1.000.013 articoli da esso singolarmente e ignorare tutto tranne l'ultimo uno.

Lo attribuirei agli sviluppatori originali semplicemente non sapendo meglio allora. Abbiamo fatto molta strada nella progettazione di OO dal 1998 circa, quando Java 2 e le collezioni sono state rilasciate per la prima volta. Ciò che sembra evidentemente un cattivo design ora non era così evidente nei primi giorni di OOP.

Ma potrebbe essere stato fatto per evitare un casting extra. Se fosse una seconda interfaccia, dovresti trasmettere le istanze delle tue raccolte per chiamare quei metodi opzionali che sono anche un po 'brutti. Così com'è ora acquisiresti subito UnsupportedOperationException e aggiusterai il tuo codice. Ma se ci fossero due interfacce dovresti usare instanceof e lanciare ovunque. Forse hanno considerato questo un compromesso valido. Anche nei primi 2 giorni di Java, instanceof era fortemente malvisto a causa delle sue prestazioni lente, avrebbero potuto cercare di impedire un uso eccessivo di esso.

Naturalmente questa è tutta una speculazione selvaggia, dubito che potremmo mai rispondere di sicuro a meno che uno degli architetti delle collezioni originali non intervenga.