Un patrón de diseño es una solución ya probada a un problema que se repite al construir software, una especie de plantilla que puedes adaptar en lugar de inventar la solución desde cero cada vez. Para el TAI, dentro del Bloque III, los tres que más suelen aparecer además del patrón MVC son Singleton, Factory y Observer. Aquí van explicados sin la jerga que suele liar más de lo que aclara.
En este artículo
- Por qué existen los patrones de diseño
- Singleton
- Factory
- Observer
- Tabla comparativa
- Por qué entender el concepto y no memorizar
- Preguntas frecuentes
¿Por qué existen los patrones de diseño y por qué caen en el TAI?
Los patrones de diseño se popularizaron a partir del libro de la llamada "Banda de los Cuatro" (Gang of Four), que catalogó soluciones que ya se repetían en muchos proyectos de software orientado a objetos. La idea de fondo es sencilla: si un problema ya se ha resuelto bien mil veces, tiene sentido reutilizar esa solución en vez de improvisar una nueva.
En el temario del TAI aparecen dentro del Bloque III (Desarrollo de Sistemas) porque forman parte de los fundamentos de la programación orientada a objetos y del diseño de aplicaciones, un apartado que suele combinarse en el examen con preguntas sobre el patrón MVC o sobre programación orientada a objetos en general.
¿Qué es el patrón Singleton?
El patrón Singleton asegura que una clase tenga una única instancia en toda la aplicación y que exista un único punto de acceso a ella. Se usa cuando necesitas que un recurso concreto (por ejemplo, la conexión a una base de datos o un archivo de configuración) se cree una sola vez y sea compartido por todo el programa, en lugar de crear una copia nueva cada vez que se necesita.
La idea clave para el examen: Singleton controla la creación de objetos para garantizar que solo haya uno, evitando duplicados innecesarios que podrían generar inconsistencias.
Ejemplo típico: el gestor de configuración de una aplicación, que lee los parámetros una sola vez al arrancar y los mantiene disponibles para todo el programa sin tener que volver a leerlos del disco cada vez que se necesitan.
¿Qué es el patrón Factory?
El patrón Factory (o Factory Method) delega la creación de objetos a un método específico, en lugar de usar directamente el operador de creación dentro del código que los necesita. Esto permite que el código que pide un objeto no tenga que saber exactamente qué clase concreta se está creando, solo que va a recibir algo que cumple una interfaz determinada.
Es útil cuando una aplicación necesita crear distintos tipos de objetos relacionados según el contexto, sin que el resto del código tenga que conocer los detalles internos de cada tipo. La idea clave para el examen: Factory separa la lógica de creación de objetos de la lógica que los usa.
Ejemplo típico: una aplicación que genera distintos tipos de documento (PDF, Word, Excel) a partir de una misma solicitud. El código que pide el documento no necesita saber cómo se construye cada formato, solo llama a la fábrica y recibe el objeto correspondiente ya creado.
¿Qué es el patrón Observer?
El patrón Observer define una relación de dependencia entre objetos, de forma que cuando uno de ellos (el "sujeto") cambia de estado, todos los que están suscritos a él (los "observadores") se enteran y se actualizan automáticamente. Es el patrón detrás de mecanismos tan habituales como las notificaciones o los eventos en interfaces gráficas: cuando pulsas un botón, varios elementos de la pantalla pueden reaccionar sin que tengan que estar consultando constantemente si algo ha cambiado.
La idea clave para el examen: Observer permite que unos objetos reaccionen automáticamente a cambios en otro, sin acoplarlos directamente entre sí.
Ejemplo típico: un sistema de alertas que avisa por correo y por notificación en pantalla cuando cambia el estado de una solicitud. Ambos canales están "suscritos" al mismo evento y reaccionan en cuanto se produce, sin que el objeto que gestiona la solicitud tenga que saber cómo se envía cada aviso.
¿Por qué merece la pena entender esto y no solo memorizar la definición?
El examen del TAI suele plantear estos conceptos con un caso práctico breve y pedir que identifiques qué patrón describe, en lugar de preguntar la definición literal. Por eso rinde más entender el problema que resuelve cada patrón (evitar duplicados, separar creación de uso, o notificar cambios automáticamente) que memorizar la frase exacta de un libro. Si tienes claro el "para qué sirve" de cada uno, reconocerlo en un enunciado distinto es mucho más sencillo.
Tabla comparativa de los tres patrones
| Patrón | Tipo | Problema que resuelve |
|---|---|---|
| Singleton | Creacional | Evitar instancias duplicadas de una clase |
| Factory | Creacional | Separar la creación de objetos de su uso |
| Observer | Comportamiento | Notificar cambios automáticamente entre objetos |
Fíjate en la columna "Tipo": es habitual que el examen pregunte si un patrón es creacional (relacionado con cómo se crean los objetos), estructural (cómo se organizan) o de comportamiento (cómo interactúan). Singleton y Factory son creacionales, mientras que Observer es de comportamiento.
Programación orientada a objetos, patrones de diseño, bases de datos y metodologías, explicados sin liarte.
Si te queda alguna duda sobre cómo encajan estos conceptos con el resto de la programación orientada a objetos, puedes revisar nuestra guía sobre programación orientada a objetos para el TAI, donde se explican las bases sobre las que se apoyan estos patrones.
No dejes el Bloque III para el final
Desarrollo de sistemas, patrones de diseño y bases de datos explicados de forma clara y directa.
Ver Bloque III por 19,99€ →Preguntas frecuentes
¿Cuántos patrones de diseño hay en total?
El catálogo clásico de la Banda de los Cuatro recoge 23 patrones, agrupados en creacionales, estructurales y de comportamiento. Para el TAI no hace falta dominarlos todos: con entender bien el propósito de los más habituales (Singleton, Factory, Observer y MVC) sueles cubrir lo que suele preguntarse.
¿MVC es también un patrón de diseño?
Sí, aunque se suele tratar aparte porque es un patrón arquitectónico que organiza toda una aplicación (separando modelo, vista y controlador), mientras que Singleton, Factory y Observer resuelven problemas más concretos dentro de esa arquitectura.
¿Hace falta saber programar para entender los patrones de diseño?
Ayuda haber visto código antes, pero el examen del TAI no te pide escribir código, sino entender el concepto y el problema que resuelve cada patrón. Con ejemplos claros y sin entrar en sintaxis concreta de un lenguaje, se puede entender perfectamente.
¿Los patrones de diseño son exclusivos de un lenguaje de programación?
No, son independientes del lenguaje. Puedes aplicar Singleton, Factory u Observer en Java, Python, C# o cualquier otro lenguaje orientado a objetos, porque describen una idea de diseño, no una sintaxis concreta.