Come gestire un gran numero di parametri opzionali

Attualmente sto sviluppando su una piccola libreria che consente di leggere e scrivere file .properties di Java mantenendo tutta la formattazione (commenti, spazio bianco, ecc.): link

Questa libreria ha un metodo saveTo per scrivere il contenuto di tale PropertyFile in un file o in un OutputStream. Al momento questo saveTo consente di assegnare un set di caratteri come parametro per specificare la codifica (se non si applica l'UTF-8 predefinito). Questo mi lascia con le seguenti firme di metodo:

saveTo(File)
saveTo(File, Charset)
saveTo(OutputStream)
saveTo(OutputStream, Charset)

Tuttavia ci sono metodi corrispondenti update e overwrite quindi ci sono in realtà altri 6 metodi (l'aggiornamento non consente un OutputStream):

update(File)
update(File, Charset)
overwrite(File)
overwrite(File, Charset)
overwrite(OutputStream)
overwrite(OutputStream, Charset)

Ora ho bisogno di introdurre un altro parametro opzionale del tipo enum MissingKeyAction .

La domanda è: come cambiare le firme del metodo per consentire, ma non richiedono i parametri facoltativi.

Vedo i seguenti approcci al momento:

1. Fornire solo alcune combinazioni di parametri. Questo è simile ad es. JOptionPane#showConfirmDialog(Component parentComponent, Object message, String title, int optionType, int messageType, Icon icon) dove devo fornire title , optionType e messageType quando in realtà desidero solo fornire un'icona .
2. Specifica un metodo sovraccarico per ciascuna combinazione di parametri facoltativi.
3. Introduci un nuovo oggetto parametro Options per incapsulare tutti i parametri facoltativi e fornisci solo un metodo con e senza un parametro Options .

Il primo approccio non è facile da usare, secondo me, dal momento che il consumatore dell'API deve specificare alcuni valori dei parametri anche se gli piacerebbe semplicemente utilizzare il valore predefinito per essi.

Il secondo approccio richiede un sacco di lavoro noioso per specificare tutte le combinazioni di metodi e finirei con un sacco di metodi sovraccaricati. Questo peggiorerebbe ulteriormente se avessi bisogno di introdurre un altro parametro!

Il terzo approccio sembra essere il migliore a mio parere in quanto non ingombra l'interfaccia, consente all'utente API di fornire solo le Opzioni in cui non vuole fare affidamento sull'impostazione predefinita ed è anche compatibile verso l'alto come faccio io Non è necessario modificare le firme dei metodi quando ho bisogno di aggiungere un altro parametro opzionale in futuro.

Se fornisco un'interfaccia fluente per la classe Options , il codice client potrebbe essere simile a questo:

import java.io.File;
import static java.nio.charset.StandardCharsets.UTF_8;

public class TestApron {
  public static void main(String[] args) {
    final Options apronOptions= Options.create()
      .with(UTF_8)
      .with(MissingKeyAction.DELETE);
    final PropertyFile propertyFile= new PropertyFile();
    propertyFile.setValue("myKey", "myValue");
    propertyFile.saveTo(new File("someFile.properties"), apronOptions);
  }
}

Come ho già detto sopra, considero questo nuovo parametro Options come la soluzione migliore e sono disposto a implementarlo.

Tuttavia voglio sentire alcune altre opinioni su questo argomento e se ci sono anche altre possibilità per affrontare questo problema a cui non ho ancora pensato.