Typescript parece tener una autodocumentación en el código, definitivamente agrega más valor que vailla Js, sin olvidar que el código en TS va a caer a JS.
Introduccion
Patrones de Diseño Creacionales en Software
Patrones Creacionales: Singleton, Factory, Abstract Factory, Builder, Prototype
Singleton
Patrón Singleton: Implementación y Uso en Programación Orientada a Objetos
Diagrama de Clases del Patrón Singleton en JavaScript
Diferencias entre JavaScript y TypeScript en patrones de diseño
Ventajas y desventajas del patrón Singleton en diseño de software
Factory
Patrones de Diseño: Introducción al Patrón Factory
Patrón Factory: Implementación y Detalles Esenciales
Implementación del Patrón Factory Method en JavaScript
Comparación del Patrón Factory en JavaScript y TypeScript
Patrón Factory: Ventajas y Desventajas en Desarrollo de Software
Abstract Factory
Patrón Abstract Factory: Estrategia para Múltiples Fábricas de Coches
Patrones de Diseño: Abstract Factory en Producción de Coches
Implementación del patrón Abstract Factory en JavaScript
Diferencias entre JavaScript y TypeScript en el patrón Abstract Factory
Patrón Abstract Factory: Ventajas y Desventajas
Builder
Patrón Builder: Diseño y Aplicación en Producción de Vehículos
Patrón Builder: Análisis de Diagrama y Clases Relacionadas
Implementación del Patrón Builder en Producción de Coches
Comparación del Patrón Builder en JavaScript vs TypeScript
Patrón Builder: Ventajas, Desventajas y Aplicaciones Prácticas
Prototype
Patrón Prototype: Clonación de Objetos en Diseño de Software
Patrón Prototype en JavaScript y TypeScript
Implementación del Patrón Prototype en JavaScript
Comparación de Prototype en JavaScript y TypeScript
Patrón Prototype: Ventajas y Desafíos en Diseño de Software
Conclusiones
Patrones Creacionales en Diseño de Software
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Diferencias entre JavaScript y TypeScript en el patrón Abstract Factory
15/27Recursos
¿Cuál es la diferencia entre las implementaciones de JavaScript y TypeScript?
A medida que nos adentramos en el diseño de software, la comparación entre JavaScript y TypeScript se convierte en un tema fascinante. TypeScript, al ser una extensión tipada de JavaScript, ofrece diferencias significativas en la manera en que podemos estructurar nuestro código. En este caso, se observa que mientras JavaScript utiliza clases para definir productos base, TypeScript opta por interfaces, permitiendo flexibilidad sin métodos concretos definidos en una clase base.
¿Por qué usar interfaces en TypeScript?
El uso de interfaces en TypeScript en lugar de clases para la definición de productos base permite una flexibilidad que es especialmente útil cuando no se requieren métodos concretos. Esta capacidad de definir el comportamiento deseado sin atarse a una implementación específica es crucial en diseños más complejos. Esto se logra mediante el uso de la palabra clave implements en vez de extends, permitiendo así una implementación más clara y efectiva de los comportamientos necesarios.
Implementación de datos y método abstracto
En TypeScript, se destaca el uso de funciones con tipos de datos claramente definidos, incluso cuando una función específica no devuelve nada actualmente. Además, la implementación abstracta de una clase factory, contrastando con el uso de interfaces, está construida para captar errores si no se implementan los métodos requeridos en las fábricas concretas. Esta diferencia señala la importancia de decidir entre herencia e implementación según los requerimientos del proyecto. La herencia es ideal para compartir una implementación común, mientras que las interfaces disponen de una estructura flexible para distintos comportamientos.
¿Cómo se benefician las abstracciones y retornos tipados?
El uso de Factory en TypeScript permite aprovechar el autocomplete, facilitando el desarrollo. Por ejemplo, cuando se implementa createMastodon, es claro que el return debe ser de tipo MastodonCar y no otro tipo de producto como MastodonSedan o Hashback. Estas diferencias no solo mejoran la comprensión del código, sino que optimizan el flujo de trabajo del desarrollador.
Ventajas de los union types en las fábricas
Una de las capacidades avanzadas de TypeScript es utilizar union types para definir los tipos de fábricas disponibles en la aplicación. Esto permite a los desarrolladores no solo definir claramente qué categorías de productos o familias se manejan, sino también asegurar el uso correcto y específico durante la codificación, mejorando la mantenibilidad y evitando errores comunes.
Reflexiones sobre las versiones de JavaScript y TypeScript
La elección entre JavaScript y TypeScript dependerá del tipo de problema que busquemos resolver. Mientras que TypeScript ofrece una mayor claridad y soporte en la fase de desarrollo gracias a su tipado estático, algunas implementaciones en JavaScript pueden ser más sencillas y rápidas para pequeños proyectos o prototipos rápidos.
¿Qué opción es mejor para tu proyecto?
En última instancia, las preferencias de diseño dependerán de tus necesidades específicas:
- TypeScript, ideal si priorizas la mantenibilidad, escalabilidad y el autocompletado optimizado.
- JavaScript, óptimo para desarrollos rápidos o cuando la configuración es menos formalizada.
Si TypeScript ha captado tu interés, te animo a explorar más sobre este poderoso lenguaje. Plataformas de aprendizaje como Platzi ofrecen recursos que sin duda potenciarán tus habilidades y mejorarán tus capacidades como desarrollador. Recuerda, el aprendizaje continuo es la clave del éxito en el mundo de la programación. ¡Sigue adelante!
Aportes 5
Preguntas 1
Ordenar por:
Sin duda alguna Typescript es un plus.
No se por que en la gran mayoria de cursos me siento que no aprendo nada, y que aveces aprendo mas con un tutorial de youtube, aqui por las rutas y los colorcitos pero creo que aveces es ver hacer cosas y ya!
//Factory no aplica porque hay maas de una familia de preoductos que se creara en la fabrica// 1 create base products clases/interfacesclass watterBottle { toFill(){throw new Error('abstract')}}class wineBottle { toFill(){throw new Error('abstract')}}// 2 (clases/interfaces) for each family of each product that are concreteclass watterGlassBottle extends watterBottle{ toFill(){ console.log('glass bottle has been fill with watter');}}class watterPlasticBottle extends watterBottle{ toFill(){ console.log('plastic bottle has been fill with watter');}
}class wineGlassBottle extends wineBottle{ toFill(){ console.log('glass bottle has been fill with wine');}}
class winePlasticBottle extends wineBottle { toFill(){ console.log('plastic bottle has been fill with wine');}}// 3 declare abstract factory that declares the creation methods for for each base productclass abstractFactory{ createWatterBottle(){throw new Error('abstract')} createWineBottle(){throw new Error('abstract')}}//4 create the actual fabsclass glassBottleFactory extends abstractFactory{ createWatterBottle(){return new watterGlassBottle() } createWineBottle(){return new wineGlassBottle()}}class plasticBottleFactory extends abstractFactory{ createWatterBottle(){return new watterPlasticBottle() } createWineBottle(){return new winePlasticBottle()}}/\*\* se mantienen los beneficios de factory+ es mas extencible \* si la clase base hay que cambiarla, hay que cambiar todo \* usalo cuando la agrupacion en familias sea posible (glass /plastic \*/function createBottleFactory(type){ const factories={ plastic:plasticBottleFactory, glass:glassBottleFactory
} const Factory=factories\[type]; return new Factory ();
}
function appBottleFactory(Factory){const watter=Factory.createWatterBottle()const wine= Factory.createWineBottle()watter.toFill();wine.toFill();}appBottleFactory(createBottleFactory('plastic'));appBottleFactory(createBottleFactory('glass'));
Creo que sería mejor que las interfaces MastodonCar y RhinoCar tuvieran métodos diferentes para que tenga más sentido, ya que ambas interfaces tienen la misma firma del método.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?