L'antipattern Poltergeists ("fantasmi") è un problema legato, come molti altri, ad una inadeguata conoscenza della programmazione Object Oriented. L'espressione classica di chi sta per incorrere in questo antipattern è: «Chissà a cosa serve questa classe? ...ma se c'è, avrà la sua importanza!».
Contesto
Come abbiamo visto nel corso di questa guida, esistono classi con troppe responsabilità, classi che "fanno” troppe cose, affette cioè da Blob. Tuttavia, esistono anche classi che hanno compiti troppo limitati, o addirittura non hanno responsabilità. Questo può accadere quando chi scrive codice non ha adeguate conoscenze di programmazione orientata agli oggetti.
Queste lacune spesso si manifestano con codice di cattiva qualità e in questo caso portano alla realizzazione di classi affette da poltergeists.
Ogni sviluppatore comprende bene l'importanza di distribuire in maniera equa le responsabilità all'interno di classi, tuttavia l'eccesso può portare o alla formazione di un "ravioli code" (che vedremo in seguito) o addirittura a classi fantasma.
La reazione di chi si trova a dover analizzare, aggiornare, utilizzare o modificare queste classi, nella maggior parte dei casi è quella di non cambiare nulla, non intervenire, lasciar tutto così com'è.
La mancanza di tempo, una documentazione incompleta, la complessità di comprendere il ruolo di quella classe nel sistema frenano qualsiasi tipo d'intervento. Queste classi, diventano, oggetti misteriosi, difficili da comprendere e dalla dubbia utilità, e come suggerisce il nome stesso, sono in molti casi difficili da identificare e classificare.
Il risultato è uno spreco di risorse, difficoltà nel documentare e porzioni di codice di cattiva qualità. In questi casi è bene non sorvolare sul problema, evitare di chiudere gli occhi, ma armarsi di pazienza e provare ad intervenire.
Cause
A causare queso antipattern c'è:
- Assenza di una corretta architettura orientata agli oggetti
- La progettazione dei componenti è stata caratterizzata da una eccessiva superficialità
- Design by committee (frequentemente questo antipattern porta alla nascita di numerosi altri problemi)
- Vengono spesso adottati ed utilizzati strumenti di progettazione inadeguati
Sintomi
Gli elementi che permettono d'individuare questo antipattern sono:
- Breve vita di oggetti e classi
- Poche righe di codice
- Classi apolidi
- Percorsi di navigazione ridondanti
- Associazioni transitorie
Conseguenze
Le conseguenze di tale antipattern sono:
- Inutile spreco di risorse
- Sviluppo di classi inefficienti
- Architettura dispersiva
- Impossibilità di effettuare il riuso
- Documentazione difficile da produrre
Soluzione
Per evitare d'incorrere in questo antipattern si possono adottare degli accorgimenti:
- Effettuare un'attenta analisi delle funzionalità delle classi Poltergeist, analizzando la documentazione disponibile
- Spostare le azioni di controllo inizialmente incapsulate nei poltergeist nelle classi connesse che essi invocano