Sebbene alcune persone possano detestare i "metodi opzionali", in molti casi possono offrire semantica migliore rispetto alle interfacce altamente segregate. Tra le altre cose, consentono la possibilità che un oggetto possa acquisire abilità o caratteristiche nel corso della sua vita, o che un oggetto (specialmente un oggetto wrapper) non possa sapere quando viene costruito quale esatta abilità dovrebbe segnalare.
Anche se difficilmente chiamerò i modelli di classi di raccolta Java di buon design, suggerirei che un buon framework di collezioni dovrebbe includere alla base un gran numero di metodi facoltativi insieme a modi di chiedere una collezione sulle sue caratteristiche e abilità . Tale design consentirà di utilizzare una singola classe wrapper con una grande varietà di raccolte senza oscurare casualmente le capacità che la collezione sottostante potrebbe possedere. Se i metodi non fossero opzionali, sarebbe necessario disporre di una classe wrapper diversa per ogni combinazione di funzionalità che le raccolte potrebbero supportare, oppure in alcuni casi alcuni wrapper potrebbero essere inutilizzabili.
Ad esempio, se una raccolta supporta la scrittura di un elemento per indice, o gli elementi in coda alla fine, ma non supporta l'inserimento di elementi nel mezzo, il codice che desidera incapsularlo in un wrapper che registrerebbe tutte le azioni eseguite su di esso sarebbe serve una versione del wrapper di registrazione che fornisca l'esatta combinazione di capacità supportate, o se nessuna di queste 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 "facoltativi", ma includeva metodi per indicare quale dei metodi facoltativi sarebbe utilizzabile, allora una singola classe wrapper potrebbe gestire raccolte che implementano qualsiasi combinazione di funzionalità. Alla domanda su quali funzionalità supporta, un wrapper potrebbe semplicemente riportare 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 che un metodo concatenate sia stato utilizzato per formare una raccolta composita di altri due, il primo dei quali era un ArrayList con 1.000.000 di elementi e l'ultimo dei quali era una raccolta di venti elementi che poteva essere solo iterata da la partenza. Se la raccolta composita è stata richiesta per l'elemento 1.000.013 (indice 1.000.012), potrebbe chiedere all'ArrayList quanti elementi ha contenuto (cioè 1.000.000), sottrarre quella dall'indice richiesto (ottenendo 12), leggere e saltare dodici elementi dal secondo raccolta, quindi restituisce l'elemento successivo.
In una situazione del genere, anche se la raccolta composita non avrebbe un modo istantaneo di restituire un oggetto per indice, chiedere alla raccolta composita per il 1000.013 ° elemento sarebbe comunque molto più veloce della lettura di 1.000.013 elementi da esso individualmente e ignorando tutti ma l'ultimo.