L'antipattern "Functional Decomposition" (decomposizione funzionale) è un problema inerente ad una errata comprensione dei principi che sono alla base della programmazione Object-Oriented. È un antipattern molto comune, frequente specie tra giovani programmatori e di difficile eliminazione.
L'espressione tipica di chi sta per incorrere in questo antipattern è: «È inutile perdere tempo con tanti formalismi, l'essenziale è che il programma funzioni».
Molti programmatori iniziano la loro formazione con linguaggi strutturali, come ad esempio il C. Le necessità lavorative o il desiderio di aumentare le proprie conoscenze, spesso, spingono ad imparare nuovi linguaggi, e la scelta, frequentemente, cade su linguaggi orientati ad oggetti, ad esempio il C++ o Java.
Tuttavia, in molti casi, la frenesia di iniziare subito a produrre codice, o la superficialità d'approccio verso questi nuovi "strumenti", porta il programmatore ad un'errata comprensione dei paradigmi che sono alla base della programmazione Object-Oriented.
Ciò che si ottiene è la scrittura di codice con un linguaggio ad oggetti ma con uno "stile" strutturale. Questa pratica, purtroppo, è molto comune e porta alla produzione di "prodotti" di dubbia qualità, ma soprattutto vengono ignorate e inutilizzate tutte le potenzialità dei linguaggi OO.
Un "mix di stili" non è mai una buona soluzione, ogni linguaggio merita il rispetto delle proprie peculiarità. La qualità finale è sempre strettamente legata ad una corretta comprensione degli strumenti che decidiamo di utilizzare.
È meglio dedicare un po' più di tempo alla fase di studio, che avventurarsi frettolosamente in stesure di codice di cattiva qualità, i risultati saranno indubbiamente migliori e la nostra "reputazione" di programmatori sarà salva. Le conseguenze, infatti, di tale errata pratica, possono essere anche gravi e rivelarsi nel corso del tempo deleterie e dai costi di manutenzione molto elevati.
La coerenza di "stile" non è mai un optional ma un requisito essenziale per qualsiasi progetto professionale.
Cause
Le cause alla base di questo antipattern sono:
- Poca conoscenza (ed esperienza) dei paradigmi OO
- Assenza di una architettura ben definita
Sintomi
Gli elementi che permettono d'individuare questo antipattern sono:
- Classi con una sola operazione
- Classi con nomi di funzioni
- Nessun utilizzo delle potenzialità offerte dai linguaggi Object-Oriented
- Sistema complesso da testare
Conseguenze
Le conseguenze di tale antipattern sono:
- Nessun uso dell'ereditarietà o del polimorfismo
- Codice poco sicuro
- Codice difficile e complesso d'analizzare e testare
- Classi difficili da documentare
Soluzione
Per evitare d'incorrere in questo antipattern si possono adottare degli accorgimenti:
- Unire le classi che hanno finalità comuni
- Analizzare il sistema mettendo in evidenza i requisiti
- Documentare adeguatamente i requisiti