Introducción
Introducción a los Patrones de Diseño
Nuestros planes para aprender patrones de diseño
El software y la ingeniería
Ingeniería de Software
Ciclo de Vida del Desarrollo de Software
Elementos de un buen diseño de software
Diseño de software
Reusabilidad
Extensibilidad
Soluciones a problemas a través de patrones
Patrones de diseño
Patrones de Diseño
Categorías de Patrones de Diseño
POO
POO y patrones de diseño
Herencia y Composición
Relaciones entre clases
Conclusiones finales
Mis dos centavos para que sigas aprendiendo patrones de diseño
You don't have access to this class
Keep learning! Join and start boosting your career
Reusability is a crucial concept in software development that not only benefits code construction, but also positively impacts product release times and costs. By reusing reliable and proven components, we free up resources to devote to other critical areas such as marketing. The next key question is: if there are proven, community-accepted solutions, why reinvent the wheel?
Reusability offers several benefits:
Despite its clear benefits, achieving effective reusability can present challenges:
Eric Gamma, one of the pioneers in design patterns, classifies reusability into three levels of abstraction, which we could associate to the preparation of a lasagna:
Like the basic ingredients of a lasagna, this is the most fundamental level of reusability:
Design patterns act as a recipe for combining ingredients effectively:
Frameworks represent the frozen lasagna:
Let's see a practical example of implementing reusability in the context of a user service using the HTTP module:
class UserService: url = " http://ejemplo.com/api"
def make_request(self): # Using HTTP module for requests response = HTTP.get(self.url) return response.data.Instead of directly using the HTTP module for each request, we could create an abstraction called HTTPGateway, which acts as an intermediary:
class HTTPGateway: def __init__(self, modulo_http): self.modulo_http = modulo_http
def request(self, url): return self.modulo_http.get(url)So, if we need to change modules in the future, we only need to modify the HTTPGateway, instead of each service that uses it. This is a sample of how a good reusability practice can facilitate software maintenance and evolution.
Reflect on when reusability is advantageous and when it can become detrimental. Have you faced these challenges in your experience as a developer? The key is to find the right balance between simplicity and functionality, always considering the most appropriate solution for each particular case. Remember, there are no universal recipes in software design; adaptability and professional judgment are your best allies.
Contributions 27
Questions 0
Niveles de reusabilidad:
Primer nivel (Clases y funciones) --> Ingredientes de la lasagna
Segundo nivel (Patrones de diseño, ¿Cómo usar las funciones y de que forma se vana conectar?) --> Receta de la lasagna
Tercer nivel (Frameworks, convenciones ¿Como manejar las rutas, peticiones, etc.) --> Lasagna congelada de tu preferencia.
El ejemplo de la abstracción utilizada en esta clase me recuerda mucho a los principios SOLID. Dentro de estos principios, hay uno muy famoso que es el de “Open-Close principle”.
Lo que este principio quiere decir es que el código debería estar abierta a la extensión, pero cerrado a la modificación.
.
Si nosotros tenemos código que ya existe y funciona, al momento de agregar una nueva funcionalidad en el software, este no debería ser modificado, sino más bien, debería ser fácilmente extensible.
El único pequeño gran problema, es que no es tan sencillo como parece. Una de las técnicas utilizadas es crear una abstracción como la vista en esta clase.
.
httpGateway es un módulo del cual dependen más de un servicio que utilizan servicios http. Si nosotros queremos agregar una nueva funcionalidad que utilice http. Podemos agregar un nuevo método a httpGateway. Este nuevo método va poder ser usado por todos los servicios que consumen a nuestra abstracción.
De esa forma el código es más fácil de extender, sin la necesidad de ser modificado.
Niveles de reusabilidad con una lasagna:
Servicios que dependen de un módulo, pero si ese módulo cambia hay que cambiar todos los servicios que lo usan.
Ahora ese servicio usa una interfaz que usa ese módulo, por lo que si cambia el módulo solo cambiamos la interfaz y no todos los servicios.
Profesor! este curso esta buenísimo
solo un comentario que se me ocurrió
¿Qué será mas grave/común que cambie?
A mi parecer, La abstracción es lo que mas comúnmente puede y deberá cambiar. Así mismo, el módulo puede cambiar por motivos de solución de bugs, extensión de sus funcionalidades u optimización lo cual puede ser grave si no utilizamos una abstracción propia de nuestro proyecto para controlarlo.
Reusabilidad:
Niveles de Reusabilidad:
La reusabilidad puede ser muy perjudicial cuando se lleva al extremo, por ejemplo, el tema de tipado de Typescript es muy común encontrarse dilemas si solo copiar tipos o abstraerlos para hacerlos reusables, lo cual se vuelve muy complejo fácilmente, debido a que es fácil caer en el error de hacer sobre ingeniería a dar tipado correctamente, en lugar de centrarse en el código como tal.
Soy nuevo en el mundo de desarrollo y trabajo sobre un software ya en produccion y siempre que tengo una nueva asigancion lo primero que hago es tratar de encontrar como reutilziar codigo ya existente y si no es posible lo neuvo que desarrollo lo hago pensnando DRY. debido a que tienod mucho a fallar en esto.
Dios mío esto es genial, desde esta clase empieza lo bueno.
Los cursos de patrones de diseño deberían estar antes de los de frameworks, pero como ya no existen las antiguas escuelas de platzi supongo que es difícil acomodar cursos dentro de las nuevas escuelas de platzi que contienen rutas.
Lo mismo está pasando con los cursos de algoritmos, y estos cursos de patrones de diseño igual, no están en ninguna ruta y al menos que llegues a buscarlos directamente no te das cuenta de que existen.
Lo cual a su vez limitan su alcance, y como ya paso con otros cursos, si no llaman la atención, no se seguirán produciendo, como los cursos de C, A un nuevo curso de CSS también le pasa.
Genial el curso, ha despejado muchas dudas
Esa pregunta del final de la clase me hizo plantearme mi existencia entera…
Yo facilmente hubiese hecho una abstraccióna sí como la de HttpGateway, pero, es mucho más probable que mi abstracción cambie antes de que lo haga el modulo http.
Si si la he utilizado desgraciadamente en el desarrollo para los jefes que imponen sus deadlines a veces no es posible pues lo importante es salir en tiempo con pruebas funcionales.
Se que es una mala practica pero prefiero tener código repetido que funciona a una método que no.
Creo que se me dificultó un poco con el ejemplo de la lasagna
¡Hola!
Algo de lo que he aprendido en toda mi ruta de aprendizaje es que una buena práctica puede ser relativa, puede depender del contexto o puede depender del programador, el principio DRY es un principio que he tratado de aplicar en mi código desde que empecé a programar, pero hay algo que es muy cierto y es, no siempre puede ser bueno abstraer, con tantas abstracciones le añadimos mucha complejidad al código, por esta razón DRY es un principio y no una regla, se recomienda que se aplique pero habrán ocasiones que no sea bueno aplicarlo, lo que más importa al final es no añadirle una complejidad innecesaria a nuestro código, el código que escribimos debemos de escribirlo para que en un futuro alguien más o nosotros mismos lo lleguemos a leer, por lo que debemos de tener un código limpio, organizado y que se auto-explique sólo sin tanta complejidad.
P.D.: Paso a recomendarles un curso en udemy que trata también este tema: Principios SOLID y Clean Code, no es muy costoso, cuándo lo compré, me salió por 10 USD apróximadamente y se complementa muy bien con este curso.
KISS over DRY
(keep it simple)
Want to see more contributions, questions and answers from the community?