Come eseguire la convalida dell'input senza eccezioni o ridondanza

Quando provo a creare un'interfaccia per un programma specifico, in genere cerco di evitare di generare eccezioni che dipendono da input non convalidati.

Quindi quello che succede spesso è che ho pensato a un pezzo di codice come questo (questo è solo un esempio a titolo di esempio, non importa la funzione che svolge, esempio in Java):

public static String padToEvenOriginal(int evenSize, String string) {
    if (evenSize % 2 == 1) {
        throw new IllegalArgumentException("evenSize argument is not even");
    }

    if (string.length() >= evenSize) {
        return string;
    }

    StringBuilder sb = new StringBuilder(evenSize);
    sb.append(string);
    for (int i = string.length(); i < evenSize; i++) {
        sb.append(' ');
    }
    return sb.toString();
}

OK, quindi dire che in evenSizerealtà è derivato dall'input dell'utente. Quindi non sono sicuro che sia pari. Ma non voglio chiamare questo metodo con la possibilità che venga generata un'eccezione. Quindi faccio la seguente funzione:

public static boolean isEven(int evenSize) {
    return evenSize % 2 == 0;
}

ma ora ho due controlli che eseguono la stessa convalida dell'input: l'espressione ifnell'istruzione e il check-in esplicito isEven. Codice duplicato, non carino, quindi cerchiamo di refactor:

public static String padToEvenWithIsEven(int evenSize, String string) {
    if (!isEven(evenSize)) { // to avoid duplicate code
        throw new IllegalArgumentException("evenSize argument is not even");
    }

    if (string.length() >= evenSize) {
        return string;
    }

    StringBuilder sb = new StringBuilder(evenSize);
    sb.append(string);
    for (int i = string.length(); i < evenSize; i++) {
        sb.append(' ');
    }
    return sb.toString();
}

OK, questo ha risolto, ma ora entriamo nella seguente situazione:

String test = "123";
int size;
do {
    size = getSizeFromInput();
} while (!isEven(size)); // checks if it is even
String evenTest = padToEvenWithIsEven(size, test);
System.out.println(evenTest); // checks if it is even (redundant)

ora abbiamo un controllo ridondante: sappiamo già che il valore è pari, ma padToEvenWithIsEvenesegue comunque il controllo dei parametri, che restituirà sempre vero, come abbiamo già chiamato questa funzione.

Ora, isEvenovviamente, non rappresenta un problema, ma se il controllo dei parametri è più complicato, ciò può comportare costi eccessivi. Oltre a ciò, eseguire una chiamata ridondante semplicemente non sembra giusto.

A volte possiamo aggirare il problema introducendo un "tipo convalidato" o creando una funzione in cui questo problema non può verificarsi:

public static String padToEvenSmarter(int numberOfBigrams, String string) {
    int size = numberOfBigrams * 2;
    if (string.length() >= size) {
        return string;
    }

    StringBuilder sb = new StringBuilder(size);
    sb.append(string);
    for (int i = string.length(); i < size; i++) {
        sb.append('x');
    }
    return sb.toString();
}

ma questo richiede un po 'di pensiero intelligente e un grande fattore di riflessione.

Esiste un modo (più) generico in cui possiamo evitare le chiamate ridondanti isEvened eseguire il doppio controllo dei parametri? Vorrei che la soluzione non chiamasse effettivamente padToEvencon un parametro non valido, innescando l'eccezione.

Senza eccezioni, non intendo una programmazione senza eccezioni, intendo che l'input dell'utente non attiva un'eccezione in base alla progettazione, mentre la funzione generica stessa contiene ancora il controllo dei parametri (se non altro per proteggere dagli errori di programmazione).

Nel caso del tuo esempio, la soluzione migliore è utilizzare una funzione di imbottitura più generale; se il chiamante desidera raggiungere una dimensione uniforme, può verificarlo da solo.

public static String padString(int size, String string) {
    if (string.length() >= size) {
        return string;
    }

    StringBuilder sb = new StringBuilder(size);
    sb.append(string);
    for (int i = string.length(); i < size; i++) {
        sb.append(' ');
    }
    return sb.toString();
}

Se esegui ripetutamente la stessa convalida su un valore o desideri consentire solo un sottoinsieme di valori di un tipo, i microtipi / i tipi minuscoli possono essere utili. Per utilità generiche come il riempimento, questa non è una buona idea, ma se il tuo valore gioca un ruolo particolare nel tuo modello di dominio, l'utilizzo di un tipo dedicato anziché di valori primitivi può essere un grande passo avanti. Qui, potresti definire:

final class EvenInteger {
  public final int value;

  public EvenInteger(int value) {
    if (!(value % 2 == 0))
      throw new IllegalArgumentException("EvenInteger(" + value + ") is not even");
    this.value = value;
  }
}

Ora puoi dichiarare

public static String padStringToEven(EvenInteger evenSize, String string)
    ...

e non è necessario eseguire alcuna convalida interna. Per un test così semplice, un int all'interno di un oggetto sarà probabilmente più costoso in termini di prestazioni in fase di esecuzione, ma l'utilizzo del sistema di tipi a tuo vantaggio può ridurre i bug e chiarire il tuo design.

L'uso di tipi così piccoli può anche essere utile anche quando non eseguono alcuna convalida, ad esempio per chiarire una stringa che rappresenta a FirstNameda a LastName. Uso frequentemente questo modello in lingue tipicamente statiche.

Come estensione della risposta di @amon, possiamo combinare il suo EvenIntegercon quello che la comunità di programmazione funzionale potrebbe definire un "costruttore intelligente" - una funzione che avvolge il costruttore muto e si assicura che l'oggetto sia in uno stato valido (facciamo il muto classe costruttore o in moduli / pacchetto di lingue non basati su classe privato per assicurarsi che vengano utilizzati solo i costruttori intelligenti). Il trucco è restituire un Optional(o equivalente) per rendere la funzione più compostabile.

public final class EvenInteger {
    private final int value;

    private EvenInteger(value) {
        this.value = value;
    }

    public static Optional<EvenInteger> of(final int value) {
        if (value % 2 == 0) {
            return Optional.of(new EvenInteger(value));
        }
        return Optional.empty();
    }

    public int getValue() {
        return this.value;
    }
}

Possiamo quindi facilmente utilizzare Optionalmetodi standard per scrivere la logica di input:

class GetEvenInput {
    public Optional<EvenInteger> askOnce() {
        int size = getSizeFromInput();
        return EvenInteger.of(size);
    }

    public EvenInteger keepAsking() {
        return askOnce().orElseGet(() -> keepAsking());
    }
}

Puoi anche scrivere keepAsking()in uno stile Java più idiomatico con un ciclo do-while.

Optional<EvenInteger> result;
do {
    result = askOnce();
} while (!result.isPresent());

return result.get();

Quindi nel resto del codice puoi EvenIntegercontare con certezza che sarà davvero pari e che il nostro controllo pari è stato scritto solo una volta, in EvenInteger::of.

Eseguire la convalida due volte è un problema se il risultato della convalida è lo stesso E la convalida viene eseguita nella stessa classe. Questo non è il tuo esempio. Nel tuo codice refactored, il primo controllo isEven che è stato fatto è una convalida dell'input, il fallimento comporta la richiesta di un nuovo input. Il secondo controllo è completamente indipendente dal primo, in quanto è su un metodo pubblico padToEvenWithEven che può essere chiamato dall'esterno della classe e ha un risultato diverso (l'eccezione).

Il problema è simile al problema del codice accidentalmente identico che viene confuso per non secco. Stai confondendo l'implementazione, con il design. Non sono la stessa cosa, e solo perché hai una o una dozzina di linee uguali, non significa che stanno servendo lo stesso scopo e che possano sempre essere intercambiabili. Inoltre, probabilmente la tua classe farà troppo, ma salta questo dato che questo è probabilmente solo un esempio di giocattolo ...

Se questo è un problema di prestazioni, puoi risolvere il problema creando un metodo privato, che non esegue alcuna convalida, che il tuo padPoEvenWithEven pubblico ha chiamato dopo aver effettuato la convalida e che invece chiamerebbe l'altro tuo metodo. Se non si tratta di un problema di prestazioni, lasciare che i diversi metodi eseguano i controlli necessari per eseguire le attività assegnate.