Critica sul principio di progettazione e validità di tali in generale

1

Speravo potessi dare un feedback su un'idea che avevo per la progettazione di funzioni.

Sto cercando di pensare a un principio unificatore per scegliere quali funzioni dovrebbero tornare. Il progetto specifico è per lo più classi di accesso ai dati.

Quindi il principio è questo: "Quando decidi quale valore restituire come codice di stato, True o False, scegli di tornare True se lo stato desiderato è raggiunto."

Ad esempio, se hai effettuato una chiamata a remove_email ('email') e l'email che hai passato come argomento non era nell'elenco, restituisci True perché lo stato desiderato, quello in cui l'email non è nel database , ora esiste. Un principio alternativo potrebbe essere, restituire sempre False se non viene eseguita l'esatta funzionalità. Mi piace rimuovere quando l'e-mail non esiste o la tabella non esiste.

Penso che un principio unificante del genere sarebbe utile per creare una mentalità condivisa nel codice in cui tutti possiamo utilizzarla come principio guida.

Quindi, prima, puoi dirmi se il principio stesso è una buona idea? Una funzione dovrebbe restituire True se in realtà non fa ciò che pretende di fare, come rimuovere un oggetto? E se questo è un cattivo principio, c'è qualche altro principio o insieme di principi che sono accettati come buoni standard? Invia sempre un codice di errore se il comportamento esatto non corrisponde? Restituisci sempre False? ecc.

E secondo, è comune avere filosofie di design comuni come questo nelle basi di codice? È così, potresti fornirmi qualche esempio? La cosa più vicina che viene in mente è la filosofia Unix secondo cui un programma dovrebbe fare una cosa e una sola cosa. Ma questo è più un principio di progettazione di livello superiore che un principio di implementazione.

Mi scuso se questa non è una buona domanda, ma sto cercando di imparare e sviluppare una strong comprensione fondamentale e voglio gestire queste idee con programmatori più esperti per ottenere feedback.

    
posta Handcre 08.01.2017 - 19:23
fonte

2 risposte

3

È una questione di gusti e stile, tuttavia una funzione, a mio avviso, dovrebbe restituire solo true o false se sta eseguendo un test. Non dovrebbe usare un valore booleano come codice di stato di un povero.

Ora, alcune basi di codice usano i codici di stato, nel qual caso un byte o un int sarà la scelta delle scelte. In questo caso è possibile scegliere di restituire uno stato diverso sul fatto che l'azione sia stata nulle o effettivamente eseguita. Questa scelta dovrebbe dipendere dal fatto che tu abbia bisogno di queste informazioni o meno. Un'altra opzione potrebbe restituire il numero di righe interessate: ecco cosa restituisce SQL quando si chiama UPDATE su una tabella.

Infine se il tuo codice base preferisce le eccezioni, allora non restituire nulla. Una funzione che aggiorna un database è normalmente void e solleva un'eccezione se necessario (ad esempio se DB non risponde).

    
risposta data 08.01.2017 - 19:52
fonte
1

Sì, è normale avere tali principi di progettazione, ma di solito dipendono dalla lingua utilizzata.

Ad esempio in C è convenzione restituire 0 se una funzione ha successo e un numero diverso da zero, indicando un codice di errore, se per qualche motivo fallisce.

Nelle lingue con eccezioni, la convenzione è di generare un'eccezione se la funzione non può eseguire l'operazione. Altrimenti si suppone che la funzione sia stata completata con successo. Quindi nessun valore viene restituito in entrambi i casi.

    
risposta data 08.01.2017 - 20:01
fonte

Leggi altre domande sui tag