L'antipattern "Blob" (noto anche come "classe dio") è un problema inerente ad una eccessiva responsabilità delle classi. È tra gli antipattern più comuni in cui si può incorrere (ed anche il più famoso).
L'espressione tipica di chi sta per introdurre questo antipattern è: "Questa classe sarà il fulcro del mio
sistema."
Contesto
Nello sviluppo di un progetto, piccolo o grande che sia, si ha sempre la necessità di lavorare con un gran numero di classi, viste come una serie di mattoncini, indispensabili per costruire il prodotto finale.
Capita, frequentemente, che alcuni programmatori, per i motivi più svariati o per un'errata comprensione dei paradigmi che sono alla basse della programmazione ad oggetti, scrivano classi iper-responsabilizzate.
Si ha l'errata convinzione che ogni sistema debba svilupparsi intorno ad un nucleo, che una classe debba necessariamente fungere da fulcro. In realtà ogni classe ha la sua importanza, le responsabilità devono essere equamente distribuite secondo logiche di implementazione ben precise. Una classe "tutto fare" non ha alcuna reale utilità, se non quella di far pensare al programmatore di aver sviluppato un componente particolarmente "potente", ed aver dimostrato con tale realizzazione le proprie capacità d'implementazione.
L'antipattern Blob, si verifica quando si concentrano troppe responsabilità in una sola classe. Tale antipattern, spesso, nasce da un'errata progettazione del componente, anche se in alcuni casi (nella maggior parte), nonostante un accurato design della classe, lo sviluppatore "mette del suo", introducendo ulteriori funzionalità, aumentando il numero di responsabilità del componente.
Cause
Le cause alla base di questo antipattern sono:
- Assenza di un'adeguata architettura ad oggetti
- Poca (spesso nessuna) padronanza dei paradigmi dell'OO
- Aggiunta indiscriminata di funzionalità nella classe
- Assenza di delocalizzazione delle responsabilità della classe
Sintomi
Gli elementi che permettono d'individuare questo antipattern sono:
- Presenza di molti metodi e attributi nelle classi
- Assenza di coesione
- Impossibilità di attuare un riuso del codice
- Difficile comprendere il reale compito della classe
Conseguenze
Le conseguenze di tale antipattern sono:
- Difficoltà del documentare adeguatamente le classi
- Eccessiva dimensione delle classi
- Difficoltà nell'apportare modifiche e aggiornamenti
- Classi con responsabilità eccessive
- Difficoltà nel testare le classi
Soluzione
Per evitare d'incorrere in questo antipattern si possono adottare degli accorgimenti:
- Accertarsi che il componente rispecchi le intenzioni progettuali
- Effettuare un'adeguata ridistribuzione delle responsabilità tra più classi
- Eliminare quelle iterazioni presenti tra classi che mostrano legami logici indiretti
- Determinare set di operazioni e di dati tra loro coesi e implementare un nuovo componente per ciascun set rilevato
