Observer y Strategy, o el Factory, son de los más obvios y con los que empiezas a darte cuenta de la utilidad de los patrones. Y sí, también es muy sencillo y he usado muchísimo el Singleton 😅
'carlos buenosvinos' tiene videos en youtube llamado 'rigor talks' donde usa PHP como base y te puedes guiar un poco con sus razonamientos, aunque quizás sea muy avanzado, ya que él tiene bastante experiencia ahí, fue mi referente cuando empecé a buscar buenas prácticas con php hace años.
Pregunta. ¿Por qué Rafa comenta en el minuto 6:44 entrecomillando que CQRS y CQS fueron inventados ambos por Greg Young?. Entiendo que el principio CQS fue descrito por Bertand Meyer en su libro “Object Oriented Software Construction” y no por Greg Young
hablando de patrones , queria consultarles especificamente sobre el patron DTO, es la tipica clase con get y set para sus atributos. Generalmente en los videos que he visto en su canal veo que no recomiendan una clase con este comportamiento, eso no sería estar en desacuerdo con este patrón? no nos aporta nada entonceS? no es que sea fan del patron DTO si no que queria saber por gente con mas experiencia por qué existe tal patron si no aporta nada? Saludos! :D
si que se utliza el patrón DTO pero para casos muy específicos, donde simplemente necesitas organizar los datos en una estructura, por ejemplo al recibir una petición http, los datos que recibes los almacenas en un DTO y una vez los valides y están correctos procederás a crear las entidades y value object correspondientes
Codely al principio del vídeo: "a nivel de implentación, no hay que quedarse con una única implementación de un patrón, es interpretable" Codely al final del vídeo: "al patrón se le respeta, cuál es tu patrón favorito?" Eso es contradictorio. "Patrón" significa "estructura que se repite". O es una estructura que se repite, y por tanto fija (de ahí que se llame "patrón") o es algo interpretable, no pueden ser las 2 cosas a la vez. Por otro lado, sí es interpretable, ¿Cómo vas a tener un patrón favorito? Por si es interpretable se entiende que dependiente de cada caso a aplicar, lo que entra en contradicción también con la denominación "patrón". No estoy mencionando si estoy de acuerdo o no con el uso de patrones, estoy diciendo que vuestro mensaje es contradictorio.
Y otra pregunta, no anulan la creatividad los patrones ? Por otro lado hay tantos que no es posible ya hacer un seguimiento y aplican a OOP, J2EE, Microservicios etc. Quizas un sintoma de exceso de exito de los GoF
Me parece que singleton se califica como anti patron, pq se utiliza mucho para tapar errores de diseño, entonces de por si nos da un code smell, pero en si al patron no le veo ningun problema si se usa cuando se debe.
Al final, tu inyector de dependencias en la mayoría de casos te va a hacer un singleton, no sería eficiente estar encapsulando toda la cadena de dependencias en cada request. Imaginate un controlador con 15 endpoints, con la misma cantidad de servicios 15 como dependencia, y estos servicios teniendo cada uno como dependencia un repo y el event bus, estaríamos hablando de que por cada request, te encapsularía 1 controlador + 15 servicios + 15 * 2 dependencias, 46 elementos compondrían ese grafo. Sale a cuenta marcar las que puedan ser signleton como singleton (en este ejemplo como minimo el repositorio y el event bus son candidatos a singleton, y depende de como programes todas podrían serlo, a mi personalmente no me gusta guardar nada en ningún servicio por lo que todas mis dependencias lo son) Eso si mucho cuidado porque si algo es singleton sus dependencias también lo son, al menos eso ocurre con Inversify o Awilix.
Están equivocados o cuando menos se contradicen: Decís que no hacen falta para programar bien. Pero que igual si eres bueno los vas a programar sin saber su nombre. Un buen programador tiene una buena comunicación técnica. Si solo tú entiendes el código que escribes y no lo puedes describir, no eres bueno; sigues siendo un junior. Los patrones son simplemente una abstracción de problemas que se repiten muchisimo al programar. No conocerlos o saber su nombre equivale a estar reinventando la rueda. Conocerlos, identificarlos y aplicarlos correctamente son lo que diferencia un novato empírico de un profesional que se ha tomado el tiempo de estudiar lo que hace y no solo resolver el problema que tiene al frente.
![[LIVE] นาทีนี้ต้องพี่ทนาย | ทนายแก้ว vs ทนายไพศาล | #คุยให้เด็กมันฟัง EP.47 (02/11/67)](http://i.ytimg.com/vi/HmquaO-PL_M/mqdefault.jpg)
Aprender patrones es el siguiente escalón, definitivamente aprender un poco, solo un poco, me abrió muchas puertas
Observer y Chain of Responsibility.
Con estos dos patrones bien usados la legibilidad y la escalabilidad del código puede aumentar exponencialmente.
Observer y Strategy, o el Factory, son de los más obvios y con los que empiezas a darte cuenta de la utilidad de los patrones. Y sí, también es muy sencillo y he usado muchísimo el Singleton 😅
Strategy es el que más me gusta ✌️
Chain of responsibility creo que es el patrón que más uso con diferencia
Casi no entendí nada, pero me resultó tan interesante que voy a empezar a estudiar al respecto . Lo mío es el PHP. Muchísimas gracias
En PHP también aplica, busca el libro Clean Architecture in PHP ... ahí explican super bien.
@@cristiangomez6041 Muchísimas gracias
'carlos buenosvinos' tiene videos en youtube llamado 'rigor talks' donde usa PHP como base y te puedes guiar un poco con sus razonamientos, aunque quizás sea muy avanzado, ya que él tiene bastante experiencia ahí, fue mi referente cuando empecé a buscar buenas prácticas con php hace años.
@@ftwtf Muchas gracias, es un avance enorme para mí. Muy, muy agradecido
@@ftwtf y está en español también. Es genial
Soy nuevo subscriptor, alabado sea este canal 😃
Command y Strategy son probablemente los que mas uso.
9:18 "Importante: al patrón se le respeta" me hizo acordar al patrón más berraco de todos: El patrón del mal JAJAJA No hace falta, me voy solo.
Están muy buenos estos videos de patrones de diseño
Que patron es escribir macros en common lisp?
El patrón "macros en common lisp". Pero se puede pensar un término mucho más rimbombante para que suene más "pro".
Mi patrón favorito es el Strategy
Patron strategy para la implementacion de metaheuristicas.
Pregunta. ¿Por qué Rafa comenta en el minuto 6:44 entrecomillando que CQRS y CQS fueron inventados ambos por Greg Young?. Entiendo que el principio CQS fue descrito por Bertand Meyer en su libro “Object Oriented Software Construction” y no por Greg Young
Pues toda la razón! Muchas gracias por el dato 😊
@@CodelyTV Por nada 😉
Yo últimamente he usado bastante el decorator.
hablando de patrones , queria consultarles especificamente sobre el patron DTO, es la tipica clase con get y set para sus atributos. Generalmente en los videos que he visto en su canal veo que no recomiendan una clase con este comportamiento, eso no sería estar en desacuerdo con este patrón? no nos aporta nada entonceS? no es que sea fan del patron DTO si no que queria saber por gente con mas experiencia por qué existe tal patron si no aporta nada? Saludos! :D
si que se utliza el patrón DTO pero para casos muy específicos, donde simplemente necesitas organizar los datos en una estructura, por ejemplo al recibir una petición http, los datos que recibes los almacenas en un DTO y una vez los valides y están correctos procederás a crear las entidades y value object correspondientes
Observer!! es mi favorito
tienen sentido cuando programas con OOP, pero cuando programas con funciones los patrones cambian
Codely al principio del vídeo: "a nivel de implentación, no hay que quedarse con una única implementación de un patrón, es interpretable"
Codely al final del vídeo: "al patrón se le respeta, cuál es tu patrón favorito?"
Eso es contradictorio. "Patrón" significa "estructura que se repite". O es una estructura que se repite, y por tanto fija (de ahí que se llame "patrón") o es algo interpretable, no pueden ser las 2 cosas a la vez.
Por otro lado, sí es interpretable, ¿Cómo vas a tener un patrón favorito? Por si es interpretable se entiende que dependiente de cada caso a aplicar, lo que entra en contradicción también con la denominación "patrón".
No estoy mencionando si estoy de acuerdo o no con el uso de patrones, estoy diciendo que vuestro mensaje es contradictorio.
el singleton es mi favorito
Strategy y State
Y otra pregunta, no anulan la creatividad los patrones ? Por otro lado hay tantos que no es posible ya hacer un seguimiento y aplican a OOP, J2EE, Microservicios etc. Quizas un sintoma de exceso de exito de los GoF
Strategy - Builder - Proxy - State - Adapter 💻
Builder
Me parece que singleton se califica como anti patron, pq se utiliza mucho para tapar errores de diseño, entonces de por si nos da un code smell, pero en si al patron no le veo ningun problema si se usa cuando se debe.
No es que sea un Anti patrón. El problema es como lo implementamos.
Al final, tu inyector de dependencias en la mayoría de casos te va a hacer un singleton, no sería eficiente estar encapsulando toda la cadena de dependencias en cada request.
Imaginate un controlador con 15 endpoints, con la misma cantidad de servicios 15 como dependencia, y estos servicios teniendo cada uno como dependencia un repo y el event bus, estaríamos hablando de que por cada request, te encapsularía 1 controlador + 15 servicios + 15 * 2 dependencias, 46 elementos compondrían ese grafo.
Sale a cuenta marcar las que puedan ser signleton como singleton (en este ejemplo como minimo el repositorio y el event bus son candidatos a singleton, y depende de como programes todas podrían serlo, a mi personalmente no me gusta guardar nada en ningún servicio por lo que todas mis dependencias lo son)
Eso si mucho cuidado porque si algo es singleton sus dependencias también lo son, al menos eso ocurre con Inversify o Awilix.
strategy
builder
Están equivocados o cuando menos se contradicen:
Decís que no hacen falta para programar bien.
Pero que igual si eres bueno los vas a programar sin saber su nombre.
Un buen programador tiene una buena comunicación técnica. Si solo tú entiendes el código que escribes y no lo puedes describir, no eres bueno; sigues siendo un junior.
Los patrones son simplemente una abstracción de problemas que se repiten muchisimo al programar.
No conocerlos o saber su nombre equivale a estar reinventando la rueda. Conocerlos, identificarlos y aplicarlos correctamente son lo que diferencia un novato empírico de un profesional que se ha tomado el tiempo de estudiar lo que hace y no solo resolver el problema que tiene al frente.
a