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
22 / 22

Ravioli Code