I parametri opzionali sono utili o un ostacolo alla manutenzione dell'applicazione? [chiuso]

I parametri opzionali hanno, secondo la mia esperienza, una buona cosa. Non li ho mai trovati confusi (almeno non più confusi della funzione effettiva), dal momento che posso sempre ottenere i valori predefiniti e sapere cosa viene chiamato.

Un loro utilizzo è quando devo aggiungere un altro parametro a una funzione che è già in uso generale, o almeno nell'interfaccia pubblica. Senza di loro, dovrei rifare la funzione originale per chiamarne uno che ha un altro argomento, e questo può diventare davvero vecchio se finisco per aggiungere argomenti più di una volta.

In generale, se hai bisogno spesso di molti / parametri opzionali, le tue funzioni stanno facendo troppo e dovrebbero essere suddivise. Probabilmente stai violando SRP (principio di responsabilità singola).

Cerca i parametri che possono essere raggruppati, ad esempio (xey, diventa un punto).

Questi flag di parametri facoltativi sono predefiniti? Se utilizzi i flag, la funzione deve essere suddivisa.

Questo non vuol dire che non dovresti mai avere parametri opzionali, ma in generale, più di uno o due parametri suggeriscono un odore di codice.

Potrebbe anche essere un indizio che la funzione, in realtà dovrebbe essere una classe, con i parametri facoltativi modificati in proprietà e la parte dei parametri richiesti del costruttore.

I parametri opzionali vanno bene

In genere la giustificazione è che a) sai di avere molti argomenti possibili per il tuo metodo ma non vuoi sovraccaricarti per paura di ridurre l'API, o b) quando non sai tutto il possibile argomenti ma non vuoi forzare il tuo utente a fornire un array. In ogni caso i parametri opzionali vengono in soccorso in un modo pulito ed elegante.

Ecco alcuni esempi:

1. Vuoi evitare di sovraccaricare e non vuoi specificare un array

Dai un'occhiata a printf () da C, Perl, Java ecc. È un ottimo esempio del potere di parametri facoltativi.

Ad esempio:

printf("I want %d %s %s",1,"chocolate","biccies");

printf("I want %d banana",1);

Nessun sovraccarico, nessun array, semplice e intuitivo (una volta che hai compreso i codici di formato stringa standard). Alcuni IDE ti diranno anche se la tua stringa di formato non corrisponde ai tuoi parametri opzionali.

2. Desideri consentire l'uso dei valori predefiniti e tenerli nascosti all'utente del metodo

sendEmail ( "[email protected]");

Il metodo sendEmail rileva che mancano vari valori essenziali e li riempie utilizzando le impostazioni predefinite definite (oggetto, corpo, cc, bcc ecc.). L'API è mantenuta pulita, ma flessibile.

Una nota su troppi parametri

Tuttavia, come altri hanno affermato, avere troppi parametri obbligatori in un metodo indica che probabilmente hai qualcosa di sbagliato nel tuo progetto. Questo è particolarmente vero se condividono lo stesso tipo poiché possono essere scambiati dallo sviluppatore accidentalmente portando a strani risultati in fase di runtime:

String myMethod(String x, String y, String z, String a, int b, String c, int d) {}

è un candidato ideale per Introduci oggetto parametro refactoring per creare

String myMethod(ParameterObject po) {}

class ParameterObject {
  // Left as public for clarity
  public String x;
  public String y;
  ... etc

}

Questo a sua volta può portare a un design migliore basato su un modello Factory con una specifica fornita come oggetto parametro.

Uno dei problemi con i parametri di default in C # (sto pensando a void DoSomething (int x = 1)) sono costanti. Ciò significa che se si modifica l'impostazione predefinita, sarà necessario ricompilare gli utenti di tale chiamata di metodo. Mentre questo è abbastanza facile da fare ci sono occasioni in cui questo è pericoloso.

Dipende da cosa sta facendo il tuo codice. Se ci sono impostazioni predefinite sensibili, è necessario utilizzare i parametri opzionali, ma se non ci sono valori predefiniti sensibili, l'aggiunta di parametri facoltativi renderà il codice più complicato. In molti casi, i parametri opzionali sono un modo pulito per evitare controlli e tagliare la logica di ramificazione. Javascript non ha parametri opzionali ma esiste un modo per emularli con || (logico o) e lo uso sempre quando faccio cose correlate al database perché se l'utente non fornisce un valore allora sostituisco i miei valori con l'aiuto di || che mi salva la fatica di scrivere un sacco di se poi affermazioni.

I parametri opzionali sono un ottimo modo per rendere semplici le cose semplici e complicate possibili contemporaneamente. Se esiste un chiaro e ragionevole valore predefinito che la maggior parte degli utenti vorrebbe, almeno nei casi di utilizzo rapido e sporco, non dovrebbe dovere scrivere il boilerplate per specificarlo manualmente ogni volta che chiama la propria funzione. D'altra parte, se le persone potrebbero avere una buona ragione per volerle cambiare, allora deve essere esposto.

L'uso di una classe IMHO è una soluzione terribile, in quanto è prolissa, inefficiente e incoerente con il tipico modello mentale di ciò che fa una classe. Una funzione è l'astrazione perfetta per un verbo, cioè fare qualcosa e ritornare. Una classe è l'astrazione giusta per un sostantivo, cioè qualcosa che ha uno stato e può essere manipolato in diversi modi. Se il primo deve essere il modello mentale dell'utente dell'API, quindi non trasformarlo in una classe.

Il problema con gli argomenti opzionali è che le persone tendono a dedicare sempre più (e più) argomenti alla funzione invece di estrarre codice rilevante in una nuova funzione. Questo è portato all'estremo in php . Ad esempio:

bool array_multisort ( array &$arr [, mixed $arg = SORT_ASC
                      [, mixed $arg = SORT_REGULAR [, mixed $... ]]] )

I parametri opzionali sono fondamentalmente un modo diverso di sovraccaricare una funzione. Quindi questo fondamentalmente si riduce a: "sta sovraccaricando una funzione male"?

Ho inizialmente apprezzato questa funzione in python e l'ho usata per estendere i metodi già utilizzati. E sembrava bello e facile, ma tornò presto; perché quando ho aggiunto un parametro facoltativo, questo stava modificando il comportamento di un metodo esistente su cui il vecchio client faceva affidamento e in un modo che non era stato rilevato dai casi di test di unità esistenti. In pratica, ciò sta infrangendo il principio Open Closed; il codice è aperto per estensione ma chiuso per modifica. Quindi credo che l'uso di questa funzionalità per modificare il codice esistente non sia una buona idea; ma va bene se usato dall'inizio

Penso che sarebbe meglio sovraccaricare una funzione con diverse firme (cioè i parametri) piuttosto che usare parametri opzionali.