Invece di scrivere un codice monolitico, mi è stato insegnato a trovare le parti di codice che possono essere riutilizzate (nello stesso codice o in altri) e creare una funzione basata su di esse, che dovrebbe eseguire "una e una sola " compito. Esiste un termine per questo stile di programmazione? Modularizzazione? È sicuramente la programmazione funzionale non , perché è qualcosa di diverso (anche se tendi a definire le funzioni e riutilizzarle anche nella programmazione funzionale).
La pratica di creare parti più piccole (potenzialmente riutilizzabili) è chiamata decomposizione funzionale . Questa è una terminologia ingegneristica generale che non si limita all'ingegneria del software.
Una pratica ancora più disciplinata è il regola una cosa : non solo le funzioni complesse vengono scomposte in parti più piccole, ma " Le funzioni devono fare solo una cosa e farlo bene " .
Questo stile da solo non ha il suo nome per quanto ne so. Tuttavia, insieme a un paio di altri principi e regole, fa parte delle pratiche Pulisci codice .
Attenzione: c'è una frequente confusione tra la regola del fai da una cosa e il principio di responsabilità singola (SRP). Questo perché entrambi sono descritti nel libro RCMartin , Clean Code, e la denominazione SRP è sfortunata e confusa . SRP non riguarda la funzionalità, ma i motivi per cui cambiare. Questo è il migliore spiegato dallo stesso Zio Bob in questo articolo
Conosco almeno 3 principi diversi che si adattano alla tua descrizione:
Il "Principio di responsabilità singola" (SRP, la "S" in SOLID) si riferisce a ciò che hai citato per funzioni con "uno e solo uno" compito.
Il principio "Non ripetere te stesso" (DRY) viene applicato quando non si copia il codice per il riutilizzo, ma lo si raffina in una funzione.
Il principio "Singolo livello di astrazione" (SLA) significa non utilizzare "riutilizzo" come unica misura per tali refactoring, ma anche utilizzare le funzioni come elementi costitutivi di un - sorpresa - un certo livello di astrazione.
Se ti ho capito bene, questi tre principi insieme dovrebbero coprire ciò che avevi in mente.
E sì, anche il termine "modularizzazione" si adatta, ma più a livello di moduli, che in genere è più grossolano delle funzioni.
Il problema è che "separare il codice" è un argomento troppo ampio perché abbia un nome specializzato. Ad esempio, la maggior parte delle implementazioni SOLID ruotano attorno all'introduzione di una separazione aggiuntiva nel codice, ma lo fanno in molti modi diversi, per svariati motivi.
E SOLID non è affatto l'unica linea guida qui, anche se sembra essere la più diffusa in OOP.
Se non altro, la difficoltà non è nel separare il codice, ma piuttosto come collegare (e ovviamente correttamente) i pezzi ora separati.
Puramente semanticamente, tendo a fare riferimento alla separazione del codice come compartimentazione :
Compartmentalize
verbTo separate into isolated compartments or categories
Questo ha qualche relazione con i campi di engineering :
When referring to engineering, compartmentalization is the general technique of separating two or more parts of a system to prevent malfunctions from spreading between or among them. This entails the breaking up of a project or problem into sub classes and sub categories, with the intention of simplifying the task at hand, or to efficiently distribute it amongst a number of teams or people.
e sicurezza delle informazioni :
Compartmentalization, in information security, whether public or private, is the limiting of access to information to persons or other entities on a need-to-know basis to perform certain tasks.
Sebbene questo sia, per quanto ne so, non un termine di programmazione stabilito, il suo significato sembra chiaro sia dalla definizione del dizionario che dalla sua applicazione in campi simili.
create a function based on them, which should perform "one and only one" task
"One and only one task" è in pratica il principio di singola responsabilità (la S in SOLID) in gioco.
Leggi altre domande sui tag programming-practices