¿Cuándo viola SRP (principio de responsabilidad única)?

SRP (PDF versión; HTML versión) establece que¿Cuándo viola SRP (principio de responsabilidad única)?

Nunca debe haber más de una razón para una clase para cambiar

Al echar un vistazo a Outlook, ventana Calendario de eventos , tiene el botón "Guardar y Cerrar".

alt text

Por eso, cuando las funcionalidades de una o ambas Guardar o Cerrar cambios, ese botón debería cambiar. Obviamente viola a SRP.

Esta funcionalidad ahorra tiempo y es conveniente ya que eso es lo que la mayoría de los usuarios esperan que haga cuando guardan un nombre en un calendario.

Pero ahora, mi pregunta es, cuando demás hacer que violan otra SRP que cuando la función tiene que ser utilizable en Outlook?

Fuente

2009-04-02 Sung

¿Qué? ¿Cómo cambia el botón al guardar o cerrar cambios? ¿Qué clase crees que implementa Save and Close? ¿Cómo afecta un cambio a esas funciones en el botón? –

Lo que quise decir con "cambio" fue eso, cuando la implementación subyacente de "guardar" o "cerrar" cambia; No cuando la IU del botón tiene que cambiar. – Sung

Mal ejemplo. La función con el código del botón tiene una _secuencia_ de dos acciones: "Guardar()" y "Cerrar()". Esto no viola nada. Cualquier función puede ser una secuencia, una iteración o una elección. –

SRP no se aplica a las IU. Tenga en cuenta que, aunque el botón se llame "Guardar y cerrar", sin duda puede haber dos métodos o tipos separados para manejar la funcionalidad de guardar y cerrar. El botón simplemente une esas dos piezas separadas de funcionalidad juntas.

Si siente la necesidad de violar el SRP, entonces necesita volver a evaluar su enfoque. Cualquier violación de SRP se puede refactorizar en un nuevo método o tipo que expone la funcionalidad compuesta por medio de la composición de las dos piezas.

Fuente

2009-04-02 14:08:28

En realidad, se aplica a la interfaz de usuario, también. Pero este ejemplo muestra una cosa de UI implementada por algunos elementos de Control y/o Modelo bajo el capó. La pregunta combina cambios de UI con cambios de Modelo/Control; lo cual no tiene mucho sentido, cada uno fue construido siguiendo SRP. –

Sí, estoy de acuerdo con usted. Después de volver a leer mi primera oración, me di cuenta de que, de hecho, soy incorrecta. Creo que lo dejaré allí ya que su comentario no tendrá mucho sentido si lo elimino. Aprecio tu comentario incisivo y no quiero que parezca fuera de contexto.:) –

@Andrew: con tu comentario, ¿te refieres a que SRP nunca debe violarse (sí, mala elección de la palabra) y, si se viola, la estructura del código debe cambiar? – Sung

¿Cuándo viola SRP (principio de responsabilidad única)?

Respuesta

Cuestiones relacionadas