Un antipatró de disseny és un patró de disseny que invariablement condueix a una mala solució per a un problema.
Quan es documenten els antipatrons, a més dels patrons de disseny, es proporciona informació i detalls als dissenyadors de sistemes per tal que no escullin mals camins, partint de documentació disponible en lloc de simplement de la intuïció.
El terme s'origina inspirat en el llibre Design Patterns, escrit per un grup d'autors conegut com a Gang of Four, i que aglutina un conjunt de bones solucions de programació. Els autors van batejar aquestes solucions amb el nom de "patrons de disseny" per analogia amb el mateix terme, usat en arquitectura. El llibre Anti-Patterns (de William Brown, Raphael Malveau, Skip McCormick i Tom Mowbray, juntament amb la més recent incorporació d' Scott Thomas) descriu als antipatrons com la contrapartida natural a l'estudi dels patrons de disseny. L'estudi formal d'errors que es repeteixen permet reconèixer i reconduir els elements involucrats cap a una millor solució. Els antipatrons no s'esmenten al llibre original de Design Patterns, ja que aquest és anterior.
Els antipatrons es consideren una part important de les bones pràctiques de programació. És a dir, un bon programador mirarà d'evitar els antipatrons sempre que sigui possible, la qual cosa requereix el seu reconeixement i identificació tan aviat com sigui possible, dins del cicle de vida del programari.
El concepte d'antipatró es pot aplicar a l'enginyeria en general, i fins i tot a qualsevol tasca realitzada per l'home. Encara que no s'escolta gaire fora del camp l'enginyeria, la noció està àmpliament estesa.
Alguns antipatrons de desenvolupament de programari Antipatrons de gestió de projectes Fum i miralls (smoke and mirrors): Mostrar com serà una funcionalitat abans que estigui implementada. Mala gestió (bad management): Gestionar un projecte sense tenir suficients coneixements sobre la matèria. Programari inflat (software bloat): Permetre que les successives versions d'un sistema exigeixin cada vegada més recursos.
Antipatrons generals de disseny de programari Base de dades com a comunicador de processos (database as an IPC): Usar una base de dades per comunicar processos en un o diversos ordinadors, quan la comunicació entre processos directa és més adequada. Blob: Vegeu Objecte totpoderós. BOMQ (Batch Over MQ): Abús en l'ús d'integració basada en missatges en temps real per a transferències esporàdiques de gran grandària en segon pla. Classe Grossa: Dotar a una classe amb gaires atributs i/o mètodes, fent-la responsable de la majoria de la lògica de negoci. Botó màgic (magic pushbutton): Tendir, al desenvolupar interfícies, a programar la lògica de negoci en els mètodes d'interacció, implementant els resultats de les accions de l'usuari en termes no suficientment abstractes. Carrera d'obstacles (race hazard): Incapacitat de preveure les conseqüències de diferents successions d'esdeveniments. Entrada nyap (input kludge): No especificar ni implementar el tractament d'entrades invàlides. Fàbrica de combustible (gas factory): Dissenyar de forma innecessàriament complexa. Gran bola de fang (big ball of mud): Construir un sistema sense estructura definida. Interfície inflada (interface bloat): Pretendre que una interfície sigui tan potent que resulta extremadament difícil d'implementar. Inversió d'abstracció (abstraction inversion): No exposar les funcionalitats implementades que els usuaris necessiten, forçant a que es reimplementin a més alt nivell. Punt de vista ambigu (ambiguous viewpoint): Presentar un model sense concretar certs aspectes, postergant així decisions conflictives. Re-dependència (re-coupling): Introduir dependències innecessàries entre objectes. Sistema de canonades de calefacció (stovepipe system): Construir un sistema difícilment mantenible, acoblant components poc relacionats.
Antipatrons de disseny orientat a objectes Acoblament seqüencial (sequential coupling): Construir una classe que necesita que els seus mètodes s'invoquin en un ordre determinat. BaseBean: Heretar funcionalitat d'una classe utilitat en lloc de delegar en ella. Fallada de classe buida (empty subclass failure): Crear una classe que no supera el test de la subclasse buida, és a dir, que es comporta de forma diferent quan s'invoca des d'una subclasse que no afegeix cap modificació. Cridar a super (callsuper): Obligar les subclasses a cridar un mètode de la superclase que ha estat sobreescrit. Model de domini anémico (anemic domain model): Usar un model del domini sense cap lògica de negoci. Això no és un enfocament orientat a objectes perquè cada objecte hauria de tenir tant propietats com un comportament associat. Objecte embornal (object cesspool): Reutilitzar objectes no adequats realment per a la fi que es persegueix. Objecte totpoderós (god object): Concentrar massa funcionalitat en una única part del disseny (classe). Poltergeist (informàtica): Emprar objectes que tenen com a únic propòsit passar la informació a tercers objectes. Problema del cercle-el·lipse (circle-ellipse problem): Crear variables de tipus pensant en els valors de possibles subtipus. Problema del yoyó (jo-jo problem): Construir estructures (per exemple, d'herència) que són difícils d'entendre a causa de la seva excessiva fragmentació. Singletonitis: Abús de la utilització del patró singleton. YAFL' (yet another fucking layer, i una altra maleïda capa més) o 'Codi Lasagna': Afegir capes innecessàries a un programa, biblioteca o framework. Aquesta tendència es va estendre força després que es publiqués el primer llibre sobre patrons.
Antipatrons de programació Nomenclatura heroica (heroic naming): Identificar els membres d'un programa (interfícies, classes, propietats, mètodes...) amb noms que fan que el conjunt aparenti estandardització d'acord amb l'enginyeria del programari però que en realitat oculta una implementació anàrquica. Acció a distància (action at a distance): Provocar la interacció no prevista de components molt distants d'un sistema. Acumular i disparar (accumulate and fire): Establir una col·lecció de variables globals per ser usades per un conjunt de subrutines. Ancora del vaixell (boat anchor): Retenir parts del sistema que ja no tenen utilitat. Bucle actiu (busy spin): Utilitzar espera activa quan existeixen alternatives. Codi dur (hard code): Fer suposicions sobre l'entorn del sistema en massa llocs de la implementació. Complexitat no indispensable (accidental complexity): Dotar de complexitat innecessària a una solució. Codi espagueti (spaghetti code): Construir sistemes l'estructura dels quals és difícilment comprensible, sobretot a causa de l'escassa utilització d'estructures de programació. Codi ravioli (ravioli code): Construir sistemes amb multitud d'objectes molt feblement connectats. Comprovació de tipus en lloc d'interfície (checking type instead of interface): Comprovar que un objecte és d'un tipus concret quan l'única cosa necessaria és verificar si compleix un contracte determinat. Confiança cega (blind faith): Descuidar la comprovació dels resultats que produeix una subrutina, o bé l'efectivitat d'un pegat o solució a un problema. Doble comprovació de bloqueig (double-checked locking): Comprovar, abans de modificar un objecte, si cal fer aquesta modificació, però sense bloquejar per comprovar-ho, de forma que la comprovació pot fallar. Fallada de caché (caching failure): Oblidar restablir una marca d'error quan aquest ja ha estat tractat. Lava seca (lava flow): Codi mort i informació de disseny oblidada que romanen congelats en un disseny canviant. Això és anàleg a un flux de lava en el qual es van solidificant trossos de roca. La solució inclou un procés de gestió de la configuració que elimina el codi mort i permet evolucionar o refer el disseny per fer créixer la qualitat. Lògica super-booleana (superboolean logic):Fer ús de comparacions o abstraccions de la lògica booleana innecessàries. Maneig d'excepcions (exception handling): Utilitzar el mecanisme de maneig d'excepcions del llenguatge per implementar la lògica general del programa. Maneig d'excepcions inútil (useless exception handling): Introduir condicions per evitar que es produeixin excepcions en temps d'execució, però llançar manualment una excepció si aquesta condició falla. Moment del codi (code momentum) : Establir massa restriccions sobre una part del sistema a causa de l'assumpció de moltes de les seves propietats des d'altres llocs del propi sistema. Nombres màgics (magic numbers): Incloure en els algorismes nombres concrets sense cap explicació aparent. Ocultació d'errors (error hiding): Capturar un error abans que es mostri a l'usuari, i reemplaçar-ho per un missatge sense importància o cap missatge. Packratting: Consumir memòria en excés a causa de no alliberar objectes reservats dinàmicament quan ja no són més necessaris. Programació per excepció (coding by exception): Afegir trossos de codi per tractar casos especials a mesura que s'identifiquen. Seqüència de bucle per casos (Loop-switch sequence): Programar un conjunt de passos seqüencials usant un bucle en combinació amb una estructura de control per casos. Cadenes màgiques (magic strings): Incloure cadenes de caràcters determinades per a fer comparacions dins el codi font, les quals el programador creu que no s'introduiran externamanet per part d'un usuari, i que poden activar certa funcionalitat oculta, esdeveniments, etc. Així, si l'usuari proporciona de manera innocent l'entrada predefinida en la cadena màgica, invocant la funcionalitat interna, la resposta del programa sovint és força inesperada per a l'usuari (apareixent així com "màgica").
Antipatrons metodològics Bala de plata (silver bullet): Assumir que la nostra solució tècnica favorita pot resoldre un problema molt major. Desenvolupament conduït per qui ho prova (tester driven development): Permetre que un projecte de programari avanci a base d'obtenir els seus nous requisits dels informes d'errors. Desfactorizació (de-factoring): Eliminar funcionalitat i reemplaçar-la amb documentació. Factor d'improbabilitat (improbability factor): Assumir que és improbable que un error conegut causi veritables problemes. Martell d'or (golden hammer): Assumir que la nostra solució favorita és universalment aplicable, fent bo la dita a un martell, tot són claus. Optimització prematura (premature optimization): Realitzar optimitzacions sense disposar de la informació suficient per fer-ho amb garanties, sacrificant decisions de disseny. Programació de copiar i pegar (copy and paste programming): Programar copiant i modificant codi existent en lloc de crear solucions genèriques. Programació per permutació (programming by permutation): Tractar d'aproximar-se a una solució modificant el codi una vegada i una altra per veure si acaba per funcionar. Reinventar la roda (reinventing the wheel): Enfrontar-se a les situacions buscant solucions des de zero, sense tenir en compte altres solucions que potser ja existeixen i que permeten solucionar els mateixos problemes. Reinventar la roda quadrada (reinventing the square wheel): Crear una solució pobra quan ja n'existeix una de bona.
Antipatrons de gestió de la configuració Conflicte d'extensions (extension conflict): Problemes amb diferents extensions que tracten de gestionar les mateixes parts del sistema (específic de Mac OS). Infern de dependències (dependency hell): Escenari de problemes produïts per les versions d'altres productes que es necessiten per fer funcionar un tercer. Infern DLL (DLL hell): Problemes amb les versions, disponibilitat o proliferació de DLLs (específic de Microsoft Windows) Infern JAR (JAR hell): Problemes amb diferents versions o ubicacions de fitxers JAR (Java), típicament causats per la falta de comprensió del model de càrrega de classes.
Alguns antipatrons organitzacionals