L'antipattern Abstractionists versus Implementationists ("astrattisti contro implementatori") è un problema dell'architettura, legato a due importanti figure professionali. Un'espressione tipica di chi sta per incorre in questo antipattern è: «Solo noi sviluppatori produciamo soluzioni reali, gli astrattisti propongono solo soluzioni tutte da verificare».
Contesto
In ogni progetto vi sono molte figure coinvolte, tra le quali, non possono mancare, per importanza e competenza: gli implementatori e gli astrattisti. Ai primi è affidato il compito di "produrre" codice; ai secondi quello della progettazione di soluzioni architettoniche, basate sul concetto di astrazione, senza occuparsi dell'implementazione materiale.
- Gli "abstractionists" basano la loro professionalità, e fondano le loro idee, sulla logica architetturale: l'abilità di definire e far comprendere l'importanza delle astrazioni è alla base di un buon software;
- Gli "implementationists", sono spinti dalla necessità di ricondurre ogni possibile astrazione a del codice per poterla comprendere meglio, preferendo a delle soluzioni astratte, delle più concrete semplificazioni implementative.
Il più delle volte, nelle decisioni progettuali, gli astrattisti perdono il confronto con il, più numeroso, gruppo di implementatori, che spesso propendono per l'adozione di soluzioni più materiali e meno astratte.
L'antipattern "Abstractionists versus Implementationists" si verifica quando le soluzioni astrattive vengono eclissate dall'adozione di implementazioni più "materiali".
Cause
Le cause che sono alla base di questo antipattern sono:
- Poca familiarità col concetto di "astrazione" da parte del team di sviluppo
- La semplicità di scrittura del codice prevale sui vantaggi di soluzioni astratte
- Poca attenzione in fase di progettazione
- Gli "astrattisti" sono privi di un reale potere decisionale
Sintomi
I dettagli che permettono di individuarlo sono:
- La complessità del software cresce in modo esponenziale
- Nessuna interazione tra implementatori e astrattisti
- Le decisioni vengono prese senza valutare le conseguenze nel lungo periodo
Conseguenze
Le conseguenze a cui si arriva cadendo in questa "trappola":
- Difficoltà nell'effettuare integrazioni, aggiornamenti e modifiche
- Problemi nella documentazione e nel testing
- Complessa manutenzione
- Impossibilità di riuso dei componenti
Soluzione
È possibile adottare alcuni accorgimenti:
- Coinvolgere, nel processo di sviluppo, programmatori con una buona formazione architetturale
- Introdurre figure professionali capaci di integrare le potenzialità dell'astrazione con le esigenze
di implementazione - Effettuare, sempre, con attenzione un'adeguata analisi di tutti vantaggi apportati da soluzioni astratte
- Il confronto e la valutazione delle soluzioni proposte devono basarsi sulla loro effettiva utilità, efficienza e potenzialità, e non in funzione dell'insistenza con cui vengono esposte
