Ci sono vincoli per le funzioni nella programmazione strutturata?

scanf e printf utilizzano stdin e stdout , il che significa diverse cose:

• Hanno effetti collaterali. Ciò significa che non sono appropriati per la programmazione funzionale e per il calcolo parallelo. Immagina due thread che leggono stdin . Quali potrebbero essere le possibili conseguenze di gestire questi fili uno accanto all'altro? Quanto sarebbe facile o difficile eseguire il debug dei problemi che appariranno solo a volte e quindi sono difficili da riprodurre?

• Crea dipendenze. Se una libreria si basa su stdin e stdout , è semplice da utilizzare in un'applicazione desktop in cui l'utente si aspetta che i dati vengano visualizzati tramite GUI anziché una console? E le applicazioni web? Per ovviare a questo problema, è possibile utilizzare l'iniezione di dipendenza, determinando in che modo la libreria interagisce con il mondo esterno invece di fare affidamento su stdin e stdout .

• Cosa succede se il programma è in esecuzione in modo automatico (al di fuori del prompt dei comandi interattivo)? Questo è spesso un problema con alcuni script della riga di comando di Linux che presuppongono che ci sia sempre un utente che può digitare Y o N per rispondere a domande specifiche. Funziona bene per scenari molto basilari e poi fallisce miseramente quando qualcuno ha bisogno di usarli in modo automatico (rimane tecnicamente possibile, solo inutilmente complicato).

• Rendono il test delle unità più difficile di quanto dovrebbe essere.

• Assumono che i moduli di input e output dovrebbero e non saranno mai configurati. Ad esempio, un metodo può printf informazioni sulla sua esecuzione per essere monitorato, il che potrebbe essere quello che ti serve per uno scenario di base. Ora, cosa succede se l'applicazione cresce e le stesse informazioni devono essere inviate a syslog? Cosa succede se deve essere filtrato?

Per quanto riguarda la funzione che fa due cose, questo è semplicemente sbagliato. Una funzione dovrebbe fare una cosa e una cosa, nello stesso modo in cui la classe dovrebbe avere responsabilità su una singola parte della funzionalità solo ( SRP ).

Lasciando che il metodo faccia più cose, i lead hanno diversi effetti:

• È molto difficile trovare un nome conciso e chiaro per la funzione. CreateProductAndRefreshCache è un brutto nome.

• Di solito porta a metodi lunghi. La suddivisione di tale metodo in due brevi passaggi spesso porta a una migliore leggibilità e manutenibilità.

• Il test dell'unità non è semplice.

Ci sono 2 cose a cui probabilmente si riferisce: effetti collaterali e componibilità.

scanf e printf do IO, che è un effetto collaterale. Gli effetti collaterali (input, output e mutazione di variabili) non si adattano molto bene alla definizione matematica di una funzione e possono rendere i programmi più difficili da ragionare, quindi c'è un paradigma di programmazione chiamato 'funzionale' che cerca di evitare tali le cose il più possibile C ++ non è in realtà un linguaggio funzionale, quindi, se è severo, probabilmente non ha senso.

Se una funzione fa 2 cose, allora può essere suddivisa in 2 funzioni che separano le cose separatamente e quindi vengono combinate. Ciò va bene per una serie di motivi: ogni singola funzione è più piccola (rendendo più facile ragionare), può essere compresa separatamente e, soprattutto, può essere combinata più facilmente con altre funzioni per fare cose nuove.