Cómo aplicar el principio de responsabilidad única a una clase de servicio

Question

Supongamos que estamos diseñando una clase UserServiceImpl que realiza operaciones CRUD (Crear, Leer, Actualizar y Eliminar). En mi opinión, Crear, Leer, Actualizar y Eliminar son cuatro razones para que una clase cambie. ¿Viola esta clase el Principio de Responsabilidad Individual? Si infringe, , entonces deberíamos tener cuatro clases como CreateUserServiceImpl, ReadUserServiceImpl, UpdateUserServiceImpl, y DeleteUserServiceImpl. ¿No es excesivo tener muchas clases de ?

Supongamos que defino 4 interfaces para cada una de las operaciones de creación, lectura, actualización y eliminación y mi clase de servicio implementa las cuatro interfaces. Ahora solo puedo tener una sola clase de implementación pero al separar sus interfaces he desacoplado los conceptos como en lo que respecta al resto de la aplicación. ¿Es esta la manera correcta o ve algunos problemas en ella?

Answer 1

No infringe el principio de responsabilidad individual hasta que el servicio sea responsable de los servicios de datos de un solo tipo o información comercial.

Answer 2

Eso es lo que me gusta de los patrones y principios - que son una forma constar que todo el mundo están de acuerdo en el diseño de software tanto como de acuerdo :-)

Mi opinión sería construir la clase de la manera que hace que sea una clase utilizable y fácil de entender, según la complejidad y el contexto en el que vive la clase. Con una implementación simple y contexto, una sola clase servirá. Se podría decir que se adhiere al SRP porque su responsabilidad es administrar las operaciones CRUD. Pero si la implementación es compleja, o hay muchos códigos compartidos que serían adecuados para colocarlos en una clase principal abstracta, entonces quizás 4 clases separadas, una para cada operación CRUD tengan más sentido. se trata de cómo lo miras.

Los patrones y principios son geniales, pero si se usan incorrectamente, pueden hacer que un problema simple sea tan complejo como no tenerlos.

Answer 3

En mi opinión Crear, Leer, Actualizar y Eliminar son cuatro razones para que una clase cambie.

¿Por qué?

Si tengo una clase Stack, ¿hay razones para que cambie la clase? Push y Pop?

No lo creo. Estas son dos operaciones estándar que las personas hacen con una pila. Lo mismo con CRUD, es un conjunto de operaciones simple, establecido y bien conocido sobre un almacenamiento de datos.

Ahora su tecnología de almacenamiento subyacente en sí ES UNA razón para que su clase cambie. Es decir, si la implementación de CRUD está codificada para que funcione solo con una instancia específica de una base de datos MS SQL 6.0, entonces usted viola SRP y la clase no será fácilmente reutilizable ni ampliable.

Con respecto a 4 interfaces, eso está más cerca de otro principio SÓLIDO, el ISP, y la necesidad aquí está determinada por los patrones de uso de su almacenamiento de datos. Por ejemplo, si algunas clases solo necesitan leer desde el almacenamiento de datos, tiene mucho sentido extraer una interfaz solo con el método Read y solicitar esa interfaz como argumento para dichos métodos. Al separar esta interfaz, puede realizar una implementación por separado.Quién sabe, tal vez para los clientes de solo lectura puede emitir una mejor consulta optimizada o utilizar un caché de memoria, pero si no, puede pasarles la instancia de almacenamiento de datos predeterminado que implementa esta interfaz.