Comparar el patrón factory en TypeScript y JavaScript revela por qué muchos desarrolladores migran al tipado estático. Si trabajas con patrones de diseño y quieres entender qué gana tu código al pasar de clases abstractas a interfaces, aquí está la respuesta directa con los puntos donde TypeScript marca distancia.

¿Por qué usar interfaces en lugar de clases abstractas?

En la versión de JavaScript dependes de una clase con métodos abstractos y una relación de herencia. En TypeScript reemplazas esa clase por una interface y cambias la jerarquía por una relación de implementación.

La diferencia no es estética. Las relaciones de herencia crean taxonomías, árboles de dependencia entre clases que se vuelven rígidos cuando el sistema crece. Una interfaz no impone esa rigidez: declara los métodos que una clase debe tener y deja que cada implementación resuelva el cómo.

En lugar de decir esta clase hereda de esta superclase, dices esta clase se comporta de esta forma. Ese cambio de enfoque, donde reemplazas extends por implements, evita problemas clásicos de la herencia múltiple y de los acoplamientos profundos.

¿Qué diferencia hay entre extends e implements? extends establece herencia entre clases y arrastra comportamiento. implements obliga a una clase a cumplir un contrato definido por una interfaz, sin heredar nada.

¿Cómo ayuda el editor cuando implementas una interfaz?

Aquí entra una de las ventajas prácticas más fuertes. Si olvidas un método al implementar la interfaz, el editor te marca el error al instante: te avisa que la clase no cumple el contrato y te indica qué método falta.

Esa retroalimentación inmediata acelera el desarrollo y reduce bugs antes de ejecutar el código. En JavaScript puro, ese tipo de error solo aparece en runtime, cuando ya es tarde.

¿Por qué los métodos factory deben retornar el tipo base?

En el paso tres también declaras el producto como una interfaz, no como una clase. Y aquí viene un detalle crítico del patrón: el método makeCar de cada fábrica no retorna un producto concreto, retorna el producto base.

¿Por qué importa tanto? Porque si en alguna parte del código usas el producto que devuelve la fábrica, no quieres depender de clases concretas. Quieres depender de la abstracción que representa la clase base del producto. Esto hace que tu código sea completamente extensible: puedes agregar nuevas fábricas y nuevos productos sin tocar el código que los consume.

En la función appFactory, cuando declaras que el parámetro es de tipo CarFactory, el editor te ofrece autocompletado. Sabe que la interfaz tiene un método makeCar y sabe que ese método retorna un BaseCar. Toda esa información viaja contigo mientras escribes.

¿Qué son los union types y por qué son útiles aquí?

En la función createFactory aparece otra herramienta de TypeScript: el union type. Un tipo union declara que un valor puede ser una de varias opciones específicas, y nada más.

En la práctica, cuando llamas a createFactory y empiezas a escribir el argumento, el editor te muestra solo las opciones válidas. No puedes pasar una cadena arbitraria porque no es lo esperado. Eso te da:

• Autocompletado preciso al escribir.
• Seguridad de que solo entran valores permitidos.
• Velocidad porque no consultas documentación externa.

¿Qué es un union type en TypeScript? Es un tipo que combina varias opciones con |. Por ejemplo, un parámetro puede aceptar solo "sedan" o "suv", y cualquier otro valor genera error en tiempo de compilación.

¿Conviene migrar de JavaScript a TypeScript para patrones de diseño?

Las ventajas concretas que TypeScript suma al patrón factory son tres: interfaces en lugar de clases abstractas, validación de implementación en el editor y union types para restringir parámetros. Cada una resuelve un dolor real que en JavaScript solo se detecta cuando el código ya falla.

La pregunta abierta es si esas ventajas justifican abandonar JavaScript por completo en tus proyectos. ¿Crees que el futuro pasa por migrar todo a TypeScript, o JavaScript sigue teniendo espacio para implementar patrones de diseño? Cuéntame tu opinión en los comentarios.