SOLID - Principio de Responsabilidad Única y de Segregación de Interfaces

🔥 ¡Aprovecha la oferta del Black Friday de CodelyTV Pro!
⮕ codely.tv/pro/...
---
Material del vídeo: codely.tv/scree...
Proceso de refactoring de un código que viola el primero de los principios SOLID: Principio de Responsabilidad Única.
Índice:
0:29 - Qué son los principios SOLID
1:28 - Contexto: Qué hace el código a refactorizar
5:12 - Violación del Principio de Responsabilidad Única - SRP
7:07 - Problemática al violar SRP
9:57 - Refactoring del método registerNewUser
17:41 - Violación del Principio de Segregación de Interfaces - ISP

[@juanpabloospinaherrera6501]

Creo que algunas personas se están llevando una idea equivocada de lo que dice el principio. SRP nos dice que una clase debe tener una ÚNICA razón de cambio, lo que cuál significa que debe tener una única responsabilidad. En ningún lado se dice que solo deba tener un único punto de entrada (ese enfoque es bastante valido pero en Use Cases en donde se utiliza el patrón Command). Pueden existir más de un método público y que solo tengan una razón de cambio, concuerdo en que es importante tener pocos, sin embargo no existe una regla que diga que debe ser un único punto de entrada, pueden existir varios y la clase seguir teniendo una única responsabilidad. Además me gustaría agregar que existen otros autores como Alan Kay que dicen que lo más importante entre los objetos son los mensajes que intercambian, por lo cual no considero que un diseño sea "bueno" o "malo", ambos son bastantes validos, y lo ideal no es llegar a puntos extremistas y buscar siempre combinar estos principios cuando sea posible para que el código que escribamos sea lo más bonito posible. Saludos. Keep coding.

[@CodelyTV]

Muchas gracias por lo constructivo y positivo de tu comentario 🙂 Podremos estar más o menos de acuerdo, pero así da gusto recibir feedback. Espero que le puedas echar un ojo a otros vídeos 😬

[@NotengolD]

El creador e impulsor de SOLID y SRP, Uncle Bob, ya nos dice en su libro de Arquitectura limpia que este principio es el que más se ha mal interpredado y muchas veces confundido con el de "las funciones deben hacer solo una cosa y solo una" el caso de SRP es que aquello que cambia por una única "razon de cambio" debe ir junto y lo que no debe ir separado, Uncle Bob aclara que esa "razón de cambio" es el usuario o quien lo solicito. Un ejemplo podría ser que dos usuarios piden un mismo reporte y se lo damos tal cual el mismo, y más adelante uno de ellos pide cambios, pues lo hacemos y que pasa que el otro usuario se ve perjudicado. Entonces que nos dice SRP que debemos darle dos reportes "identicos" y así si uno pide cambios los demás usuarios no se verán afectados. Saludos tiene buenos videos.

[@ciltocruz]

A mi este principio me sigue chirriando una barbaridad por el dónde o cuándo se empieza a aplicar. Si todos los métodos de una clase tienen que usar todas las dependencias de una clase y sus variables entonces pasaría lo que muchos otros comentan por aquí: acabaría habiendo un método público (con alguno privado por aquello de hacer el código más legible) por clase. No sé. No termino de verlo en proyectos grandes o tiendas online, donde hay productos, pedidos, usuarios, clientes, formas de pago... El proyecto tendría muchísimas clases y no tengo claro que eso ayude a la legibilidad. Pero bueno, seguiré viendo vídeos de este canal a ver si veo algún otro ejemplo más complejo. ¡Saludos!

[@calshox]

Gracias por la explicación. ¿Pero no pasaremos de tener una clase cajón desastre con 1000 funciones a un directorio cajón desastre con 1000 clases de una función?

[@CodelyTV]

+Carlos Vázquez correcto. El tema está en que a pesar de que lo parezca, no estamos simplemente trasladando el problema de un lado a otro. Hay muchos matices al hacer este cambio que se deben tener en cuenta. Me explico: Si tienes 1000 responsabilidades en una clase: - A esta clase se le deberán inyectar las 5000 dependencias o colaboradores en el constructor necesarios para poder ejecutar cualquiera de los 1000 métodos. - Por tener 1000 responsabilidades en la clase, seguramente evitemos crear métodos privados que provean de semántica al código ya que tendremos el concepto "esta clase ya tiene muchos métodos" en la cabeza. Con lo cuál, será menos legible. Reconozco que esto es algo subjetivo, pero en mi caso me pasa. Si tienes las 1000 responsabilidades en clases aisladas: - Cada clase tendrá únicamente sus dependencias. A nivel de rendimiento y testabilidad, esto es crucial. - Como una clase sólo hace una cosa, no nos tenemos por qué cortar a la hora de definir métodos privados que sirvan para encapsular parte de esa lógica proveyendo de semántica al código - Desde el momento en el que tenemos este nivel de granularidad, la reutilización de código se hace mucho más viable. Espero haberme explicado y muchas gracias por la pregunta, seguro que le puede servir a alguien más :)

[@victoraguileralara]

@@CodelyTV Me hace mucho sentido. Comenzaré a programar de esta forma

[@10crack8]

Lástima que no seguiste con todos los principios SOLID (como el de Liskov que es el más difícil de entender a priori) porque está bien explicado y el ejemplo es muy fácil de entender.

[@paolagalarza2823]

Muy buena explicacion .... seria genial que tambien expliques Subtitucion Liskov

[@cristianandresvargasgonzal4510]

hola gracias por el video, en cuanto a la segregacion de interfaces, podriamos utilizar una clase abstractas de php para que dejaramos todos los metodos correspondientes a DatabaseRepository y ya no seria una obligacion tener que llamar a esos dos metodos en las clases que las implementan, es posible que se cumpla de esta forma ese principio de solid?

[@ronyaleittelagos4803]

Ese DataBaseRepository, ¿es solo para user?. Y para clientes, ¿tendría que crear un DataBaseRepository para cliente?

[@NicolasMarulanda]

Para mi eso de empezar a crear clases y clases y que solo tenga un par de métodos no me cabe en la cabeza, aun que es normal, como en el ejemplo del video yo también crearía los métodos para administrar un usuario (registro, inicio de sesión, etc) en la clase UserManager, con ello se que todo lo relacionado con usuarios esta en esa clase. En fin, estoy viendo este tema ya que en el proyecto web que estoy desarrollando, para poner en practica lo que voy aprendiendo, veo que no tengo claro algunos conceptos.

[@CodelyTV]

Buenas Nicolás! Como respondíamos a Carlos en un comentario anterior, los beneficios de segregar las distintas responsabilidades de gestión de usuarios en distintas clases evitando así los típicos `XxxxManager` serían: Si tienes 10 responsabilidades en una clase (ejemplo `UserManager`): - A esta clase se le deberán inyectar las 50 dependencias o colaboradores en el constructor necesarios para poder ejecutar cualquiera de los 10 métodos. - Por tener 10 responsabilidades en la clase, seguramente evitemos crear métodos privados que provean de semántica al código ya que tendremos el concepto "esta clase ya tiene muchos métodos" en la cabeza. Con lo cuál, será menos legible. Reconozco que esto es algo subjetivo, pero en mi caso me pasa. Si tienes las 10 responsabilidades en clases aisladas: - Cada clase tendrá únicamente sus dependencias. A nivel de rendimiento y *testabilidad*, esto es crucial ya que nos ayudará enormemente. - Como una clase sólo hace una cosa, no nos tenemos por qué cortar a la hora de definir métodos privados que sirvan para encapsular parte de esa lógica proveyendo de semántica al código. - Desde el momento en el que tenemos este nivel de granularidad, la reutilización de código se hace mucho más viable. ¡Saludos!

[@nmolocho]

Hola ..que tal me gustaria saber cual es el IDE de desarrollo que manejas en el video

[@CodelyTV]

Buenas! El IDE es PhpStorm, de la compañía IntelliJ. Aquí tienes un vídeo con tips para configurarlo: kzbin.info/www/bejne/bYq9h4yCo6yKmM0 y aquí otro sobre el estilo de código (también con tips): kzbin.info/www/bejne/mIanYneDo8uJf7s Próximamente grabaremos otro sobre atajos de teclado y demás 🙂

[@javi68yt2]

entonces, ¿mejor tener una clase por responsabilidad? algo del tipo UserManager ()

[@CodelyTV]

Buenas Javi! * "¿mejor tener una clase por responsabilidad?" -> Correcto! :) * "tipo UserManager ()" -> No somos muy amigos de los sufijos tipo "Manager" ya que abren la puerta a que dentro metamos varias cosas. Con lo que directamente "User

[@josealb94dev]

Este principio aplica cuando mi clase tiene atributos, pero que pasaría si tengo una clase que solo tenga métodos, por ejemplo, una clase llamada FormatoFecha, con métodos: aammdd(fecha), otra aaaammdd(fecha) y asi varios métodos. Se debería aplicar lo mismo o que acciones debería tomar?

[@andymarinosrodriguez2170]

Es una clase utilería, yo pienso que ahí debes tener los métodos necesarios referente a conversiones, parseos, etc

[@thevolcomstone10]

Hola viendo el vídeo por cierto muy bueno, recomiendas generar una clase por cada caso de uso y este definirlo en Application > Service ?, Es que aun no comprendo muy bien. Ejemplo si tengo un CRUD de User, tengo que tener una clase UserCreateUseCase, UserReadUseCase, UserUpdateUseCase, UserDeleteUseCase, y estas a la vez un único método que define la accione a realizar ?

[@CodelyTV]

Buenas Alan! No tengo claro si para una aplicación CRUD que no tenga mucha lógica de negocio merece la pena la inversión en términos de separación en capas y demás. En cualquier caso, sí. Los casos de uso deberían estar aislados en clases separadas. Los beneficios de esto los describíamos en este otro comentario: kzbin.info/www/bejne/mWqagWSLoqtkmdU&lc=z12ewf3h5nmdxxdec22zzx3zovjrihi1n.1444044539103872 Cualquier duda, aquí estamos :)

[@CodelyTV]

El repositorio quedaría con firmas simples del tipo `find`, `save`, `update`, y `delete`. Tienes más información de cómo interaccionar con componentes de infraestructura en el vídeo sobre el principio SOLID de inversión de dependencias (DIP): kzbin.info/www/bejne/i5SbeX6LjdppadE y en el vídeo de introducción a Arquitectura Hexagonal: kzbin.info/www/bejne/fYucmpZvhriCa7c Saludos!

[@silverte2]

@@CodelyTV Pero entonces el patrón repositorio estaría rompiendo con el principio de responsabilidad única no?

[@CodelyTV]

Esto justamente es algo en lo que hemos cambiado de opinión -termino "opinión" usado con toda la intencionalidad ya que al fin y al cabo sólo es eso, nuestra forma de verlo 👼-. Antes sí que habría separado en UserWriterRepository y UserReaderRepository. Con el tiempo y al menos en los casos que nos hemos ido encontrando, hemos visto que es algo que en el 90% de los escenarios va muy de la mano y, si cambias la estructura de BD para escribir, seguramente cambie también para leer. Con lo cuál, hemos acabado prefiriendo mantener estas 2 operaciones a nivel de repositorios cohesionadas en la misma clase. Al final se trata de evaluar qué pros/contras tenemos y tirar palante con lo que más te compense en tu contexto 😊

[@silverte2]

@@CodelyTV Excelente, pensaba en algo similar seria bueno hacer un vídeo comentando estos puntos desde su perspectiva mas actualizada por así decirlo

[@fralurbe]

Muy buen video. Metes mal el acento al decir instancia.