Aplicación del principio de responsabilidad única en un botón

7

Tengo una clase que representa un botón en la pantalla. Esta clase tiene dos métodos: uno para evento de clic; el otro para el evento de clic largo. Ambos eventos hacen cosas diferentes.

Entonces, de acuerdo con el Principio de Responsabilidad Única, una clase debe ser responsable de una cosa, luego debe ser solo una cosa que te obliga a cambiar de clase. Si cada evento es diferente, ¿debo crear 2 clases para cada evento?

Además, ¿alguien tiene un ejemplo complejo de este principio? Solo puedo encontrar el caso del empleado. Es fácil de entender, pero me gustaría leer una que sea más compleja.

    
pregunta korima 13.10.2014 - 18:20

3 respuestas

9

La mayoría de los ejemplos del mundo real que he encontrado son demasiado simples o demasiado complejos para explicarlos aquí. Recomendaría consultar los artículos de BlackWasp sobre SRP . (Gran parte del contenido de ese sitio puede resumirse como se muestra a continuación).

Del hombre que creó el término Principio de responsabilidad única:

  

... Este principio es sobre las personas .

     

Cuando escribe un módulo de software, desea asegurarse de que cuando se solicitan los cambios, dichos cambios solo pueden originarse en una sola persona, o más bien, en un solo grupo de personas estrechamente acopladas que representan una única función empresarial definida de manera muy restringida. Desea aislar sus módulos de las complejidades de la organización en su conjunto y diseñar sus sistemas de modo que cada módulo sea responsable (responda) a las necesidades de esa única función empresarial.

     

¿Por qué? Porque no queremos que se despida al COO porque hicimos un cambio solicitado por el CTO. Nada aterra más a nuestros clientes y gerentes que descubrir que un programa funcionó mal de una manera que, desde su punto de vista, no tenía ninguna relación con los cambios que solicitaron. Si cambia el método calculatePay y rompe inadvertidamente el método reportHours ; luego el COO comenzará a exigirle que nunca cambie el método calculatePay nuevamente .

Continúa para volver a establecer el SRP en términos más simples:

  

Otra redacción para el Principio de Responsabilidad Única es:

     
    

Reúna las cosas que cambian por las mismas razones. Separe las cosas que cambian por diferentes razones.

  

Wikipedia tiene una definición más sencilla :

  

En la programación orientada a objetos, el principio de responsabilidad única establece que cada contexto (clase, función, variable, etc.) debe tener una responsabilidad única, y que la responsabilidad debe estar completamente encapsulada por el contexto. Todos sus servicios deben estar estrechamente alineados con esa responsabilidad.

Lo que específicamente te dice que puedes tener una clase que causa muchos otros cambios, según la interacción con la clase (o botón) especificada.

Continúa para dar el ejemplo de una clase de informe:

  

Martin define una responsabilidad como razón para cambiar , y concluye que una clase o módulo debe tener una, y solo una, razón para cambiar. Como ejemplo, considere un módulo que compila e imprime un informe. Tal módulo puede ser cambiado por dos razones. Primero, el contenido del informe puede cambiar. En segundo lugar, el formato del informe puede cambiar. Estas dos cosas cambian por causas muy diferentes; Una sustantiva, y una cosmética. El principio de responsabilidad única dice que estos dos aspectos del problema son en realidad dos responsabilidades separadas y, por lo tanto, deberían estar en clases o módulos separados. Sería un mal diseño juntar dos cosas que cambian por diferentes razones en diferentes momentos.

    
respondido por el Adam Zuckerman 14.10.2014 - 00:05
4

Estoy de acuerdo con El comentario de Ampt :

  

Si asume que la responsabilidad de los botones es aceptar la entrada del usuario y llamar al método apropiado, entonces no está violando el SRP.

En su caso, sería más importante distinguir entre funcionalidad y presentación: separar la GUI y el código que se ejecuta al hacer clic en el botón. El manejo de eventos es parte de la GUI, por lo que puede permanecer allí, pero no recomiendo la combinación de la funcionalidad real del botón con la GUI.

Este debe ser su enfoque de SRP en este caso particular. Como suele suceder con SRP, mantener la presentación y el código separados puede ser muy útil. Hay una razón por la cual las arquitecturas como MVC son tan populares.

    
respondido por el Seralize 14.10.2014 - 01:24
0

Su clase de botón hace hace solo una cosa: administra el estado del botón. El hecho de que el botón pueda hacer varias cosas o tenga múltiples comportamientos no tiene relación con el principio de responsabilidad única.

El principio donde se aplica es en la implementación: si el botón tiene dos comportamientos, cada comportamiento debe realizarse a través de un método diferente. No cree un método que maneje ambos a través de una serie de declaraciones if.

    
respondido por el Bryan Oakley 14.10.2014 - 13:13

Lea otras preguntas en las etiquetas