Tienes ejemplos geniales de principios SOLID que quieras compartir? ¡Déjalos en nuestro repositorio y ayúdanos a enriquecer esta valiosa colección de conocimientos! 💬👨‍💻 Recuerden dejar su like, comentar y comparir?

Gracias rey; muy top la explicación 🎉

@JamiltonQO

Ай бұрын

Esooooo buena mi rey muchas gracias que bueno que te gustara

En caso tengamos un código ya existente como el ejemplo del package "sin", ¿ no estaríamos rompiendo el "open-closed" al editarlo para dejarlo como el ejemplo del package "cono" ?. Mi duda es si esto solo se debe aplicar durante el desarrollo, pero para código ya existente donde queremos mantener las clases, aplicar otra alternativa, tal vez herencia sin modificación.

@JamiltonQO

27 күн бұрын

Hola Rafael, Qué buena pregunta. No, al hacer refactor no rompes el principio de Open/Close porque estás mejorando la legibilidad y la escalabilidad del producto. El código no es estático; puede que hoy inicie de una forma y mañana tengas que cambiarlo. Eso no significa romper el principio. Romperlo es cuando, al crearlo, ya lo inicias con una mala práctica, porque si no, tendrán que lidiar con ese código malo toda la vida. Es, de hecho, una buena práctica, como dice el Tío Bob en su libro Clean Code, "la regla del Boy Scout": dejar el campamento (código) mejor de lo que se encontró, y eso muchas veces implica un refactor. Así que no te dé miedo cambiar algo que ya está por una mejor práctica.

Entonces si tenemos al menos 2 casos de uso en una clase, ¿ Deberíamos siempre aplicar este principio "open-closed" anticipando futuros cambios o en qué escenario no deberíamos aplicarlo ?

@JamiltonQO

28 күн бұрын

Saludos Rafa buen día. Muy buena pregunta. La respuesta general sería no. Por qué siempre de como lo mencionas el caso de uso y la solución concreta si solo es posible dos opciones y en negocio ven que no va a escalar o que de hecho solo tienes una posible opción no tiene sentido complicarse aplicando patrones. Lo que si deberías pensar siempre es como hago para que mi clase quede cerrada y eso es separando bien las responsabilidades. Si a nivel de negocio te dicen que puede escalar y eso es tu trabajo cuando estés levantando los requisitos sabrás si debes pensar en planear un buen diseño escalable y resiliente a los cambios o no

@JamiltonQO

28 күн бұрын

Creo que es importante no ser digamos en cierto sentido "extremistas" al decir... Siempre todo de verdad sonara cliché pero es según el caso de uso y tu problema concreto.

El enlace de discord expiró jamilton

@JamiltonQO

Ай бұрын

A juemadre =( no puede ser muchas gracias ya mismo lo genero de nuevo. Gracias por avisar