Gran vídeo, pero se me ocurre un paso más allá: De la misma forma que un Hero tiene una Id (Warrior, Paladin,...) y un Weapon tiene una id (Sword, Shield,...), puede existir una interfaz Factory que tenga una id (Hero, Weapon,...) y la abstract factory en lugar de tener una HeroFactory y una WeaponFactory, tendría un Factory[ ], y crearíamos una FactoryConfiguration para cada caso que queramos. Luego habría un consumer que directamente le dice a la AbstractFactory el tipo de factoría y lo que quiere. De igual manera que el Consumer anterior tenía que dar una id existente al hacer battleFactory.Create("Warrior"), ahora el Consumer tendría que dar Ids válidas para el tipo de factoría y el producto, es decir abstractFactory("Hero","Warrior"). Lo que devolvería sería un AbstractFactoryProduct y....... no sé a dónde estoy yendo, tiene sentido todo esto??? ajjajajajajajajajajjja
Muchas gracias por todo, sería q genial q pudieras organizar tus videos y catalogarlos para que sean como una guía progresiva, como ya t dije antes, tu canal es de las pocas joyas q hay, y con el tiempo irá creciendo más a medida que los que agarramos unity, tengamos el nivel para llevar estos cursos :v
Duda, ¿La alternativa a utilizar Abstract Factory sería acoplar, en este caso, el arma al heroe verdad? En Factory Pattern muestras que la alternativa era un switch y se ve claramente la mejora pero en este caso me cuesta ver esa "alternativa mala". Si el arma está acoplada al heroe pero la configuración viene de servidor, ¿Por qué iba a necesitar un abstract factory?
La alternativa mala sería tener el new y el switch en el héroe. Si mañana tienes que cambiarlo tendrás que modificar el héroe, eso incumple el principio de SRP. Además el héroe conocería todas las armas, no solo las que vaya a utilizar. Esta es una construcción bastante sencilla, pero a la que se complique le estarás dando toda la responsabilidad al héroe, y no es su responsabilidad construir armas. (Como alternativa mala estoy seguro de que encontraríamos mil formas de hacer lo mismo bien acopladitos, los programadores no tenemos límites para acoplarnos, jajajaja)
@@ThepowerupsLearning Genial :D suponía que la "alternativa mala" sería un acoplamiento directo del arma al heroe pero no acababa de ver el escenario concreto que planteas con el Switch de armas. Gracias :D
Uufff! Qué maravilla mi buen Dani! Tengo una pequeña pregunta por el minuto 11:22, empiezas a agregar la instancia de la configuración para la factoria de HalloweenWeapons y pues su creación en el Start. Si ahora yo quisiera agregar lo mismo pero para una de navidad, y luego año nuevo y otras fiestas y eventos constantemente estaría rompiendo el principio Open-Close, no? Lo correcto sería comenzar a abstraerlo, no? Cómo recomendarías hacerlo? Espero estés muy bien! Un gran saludo mi buen! :D
¡Hola Alan! Sí, lo puedes abstraer, podrías crear un SO que contuviese un array con todas las configuraciones y crear la factoría para todas ellas. Necesitarías también añadir algún dato para saber que factoría es la que tiene que utilizar, como una fecha de inicio y fin, o cualquier condición que te ayuda a saber cual es la buena. ¡Un saludo!
❤️ Curso de Patrones de diseño para VIDEOJUEGOS: bit.ly/3k38KE1
🔵 Discord: discord.gg/KWABp4BfN4
🕹 Blog: thepowerups-learning.com/
👆👆👆👆👆👆👆👆👆👆
Gran vídeo, pero se me ocurre un paso más allá: De la misma forma que un Hero tiene una Id (Warrior, Paladin,...) y un Weapon tiene una id (Sword, Shield,...), puede existir una interfaz Factory que tenga una id (Hero, Weapon,...) y la abstract factory en lugar de tener una HeroFactory y una WeaponFactory, tendría un Factory[ ], y crearíamos una FactoryConfiguration para cada caso que queramos. Luego habría un consumer que directamente le dice a la AbstractFactory el tipo de factoría y lo que quiere.
De igual manera que el Consumer anterior tenía que dar una id existente al hacer battleFactory.Create("Warrior"), ahora el Consumer tendría que dar Ids válidas para el tipo de factoría y el producto, es decir abstractFactory("Hero","Warrior"). Lo que devolvería sería un AbstractFactoryProduct y....... no sé a dónde estoy yendo, tiene sentido todo esto??? ajjajajajajajajajajjja
Muchas gracias por todo, sería q genial q pudieras organizar tus videos y catalogarlos para que sean como una guía progresiva, como ya t dije antes, tu canal es de las pocas joyas q hay, y con el tiempo irá creciendo más a medida que los que agarramos unity, tengamos el nivel para llevar estos cursos :v
Tus videos me han ayudado a mejorar mi código, buen trabajo
¡Gracias! ¡Me alegro mucho!
No me pierdo ninguno !! Ánimo
¡Mil gracias por el apoyo! 😁
Eres el youtuber de youtubers un saludo crack
¡Jajaja! ¡Aún me queda mucho por mejorar pero gracias!
Uff el potencial de esto con addressable assets :O
💪💪💪
Luego, a las armas les puedes dar diferentes stats dentro de sus clases específicas, no?
Buen video! Suuuuper útil!! :D
¡Gracias! 💪
En el esquema UML dice que el heroe tiene que ser interface, pero luego no te veo implementarlo. Me puedes explicar, porfa?
Duda, ¿La alternativa a utilizar Abstract Factory sería acoplar, en este caso, el arma al heroe verdad?
En Factory Pattern muestras que la alternativa era un switch y se ve claramente la mejora pero en este caso me cuesta ver esa "alternativa mala".
Si el arma está acoplada al heroe pero la configuración viene de servidor, ¿Por qué iba a necesitar un abstract factory?
La alternativa mala sería tener el new y el switch en el héroe. Si mañana tienes que cambiarlo tendrás que modificar el héroe, eso incumple el principio de SRP. Además el héroe conocería todas las armas, no solo las que vaya a utilizar.
Esta es una construcción bastante sencilla, pero a la que se complique le estarás dando toda la responsabilidad al héroe, y no es su responsabilidad construir armas.
(Como alternativa mala estoy seguro de que encontraríamos mil formas de hacer lo mismo bien acopladitos, los programadores no tenemos límites para acoplarnos, jajajaja)
@@ThepowerupsLearning Genial :D suponía que la "alternativa mala" sería un acoplamiento directo del arma al heroe pero no acababa de ver el escenario concreto que planteas con el Switch de armas.
Gracias :D
Uufff! Qué maravilla mi buen Dani!
Tengo una pequeña pregunta por el minuto 11:22, empiezas a agregar la instancia de la configuración para la factoria de HalloweenWeapons y pues su creación en el Start. Si ahora yo quisiera agregar lo mismo pero para una de navidad, y luego año nuevo y otras fiestas y eventos constantemente estaría rompiendo el principio Open-Close, no?
Lo correcto sería comenzar a abstraerlo, no? Cómo recomendarías hacerlo?
Espero estés muy bien! Un gran saludo mi buen! :D
¡Hola Alan!
Sí, lo puedes abstraer, podrías crear un SO que contuviese un array con todas las configuraciones y crear la factoría para todas ellas. Necesitarías también añadir algún dato para saber que factoría es la que tiene que utilizar, como una fecha de inicio y fin, o cualquier condición que te ayuda a saber cual es la buena.
¡Un saludo!
0:39 No , no me ha explotado la cabeza , sencillamente , porque no entendí nada de lo que dijo XD .
😅😅