Functional Decomposition

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