¿Cuál es la diferencia entre el principio de responsabilidad única y la separación de preocupaciones?
Respuestas:
Principio de responsabilidad única (SRP): dé a cada clase una sola razón para cambiar; y “Razón para cambiar” == “responsabilidad”. Por ejemplo: la clase de factura no tiene la responsabilidad de imprimirse.
Separación de preocupaciones (desde 1974). Preocupación == característica del sistema. Cuidar cada una de las inquietudes: para cada inquietud, otras inquietudes son irrelevantes. Ocultar la implementación del comportamiento.
De aqui .
En mi opinión, el principio de responsabilidad única es una de las herramientas / modismos para lograr la separación de preocupaciones.
Separación de preocupaciones vs principio de responsabilidad única (SoC vs SRP)
Del artículo vinculado:
Separación de preocupaciones (SoC) : es el proceso de dividir un programa de computadora en características distintas que se superponen en la funcionalidad lo menos posible. Una preocupación es cualquier parte de interés o enfoque en un programa. Por lo general, las preocupaciones son sinónimos de características o comportamientos. http://en.wikipedia.org/wiki/Separation_of_concerns
Principio de responsabilidad única (SRP) : cada objeto debe tener una sola responsabilidad y todos sus servicios deben estar estrechamente alineados con esa responsabilidad. En cierto nivel, la cohesión se considera sinónimo de SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle
La Responsabilidad Única establece que un Objeto es responsable de una sola unidad de trabajo.
La separación de preocupaciones establece que las aplicaciones deben dividirse en módulos cuyas funcionalidades se superpongan lo menos posible.
Resultados finales similares ... aplicaciones ligeramente diferentes.
El principio de responsabilidad única y la separación de preocupaciones son realmente lo mismo.
Seguro que puede empantanarse en una discusión académica tratando de desentrañar algún tipo de diferencia entre los dos, pero ¿por qué? A todos los efectos, describen lo mismo. El mayor problema es que la gente está tan atrapada en el deseo de saber exactamente qué son una "preocupación" y una "responsabilidad", que tal vez pierdan la idea importante detrás de SRP y SoC.
Esa idea es simplemente dividir su base de código en partes aisladas poco acopladas. Esto permite que varios desarrolladores trabajen en diferentes partes sin afectar a los demás, también permite que un solo desarrollador modifique una parte aislada sin romper otra.
Esto se aplica a nivel de módulo, por ejemplo, MVC es un patrón arquitectónico que promueve SRP y SoC. El código base se divide en modelos, vistas y controladores aislados. De esa forma, la modificación de una vista se puede realizar independientemente de un modelo. Dos dos no están horriblemente entrelazados.
En un nivel inferior, esto también debería aplicarse a las clases. En lugar de poner docenas de métodos en una sola clase, divida el código en varios. Por las mismas razones.
También, incluso a nivel de método, divida los métodos grandes en métodos más pequeños.
En principio. SRP es un principio, no una regla, por lo que no tienes que (léase: no puedo / no debes) seguirlo religiosamente al extremo. No significa ir demasiado lejos y tener solo un método de siete líneas en cada clase, por ejemplo. Simplemente significa un principio general de dividir el código en partes aisladas. El punto es que conducirá a una mejor base de código y un software más estable.
Separación de preocupaciones (SoC). Divida su aplicación en distintas funciones con la menor superposición de funciones posible. (Microsoft).
"Preocupación" = "característica distintiva" = "sección distinta"
La "preocupación" funciona tanto en niveles altos como bajos
El principio de responsabilidad única establece que cada módulo o clase debe tener la responsabilidad sobre una sola parte de la funcionalidad proporcionada por el software, y esa responsabilidad debe estar completamente encapsulada por la clase. Todos sus servicios deben estar estrechamente alineados con esa responsabilidad. (Definición de Wikipedia)
“Responsabilidad” = “razón para cambiar” ¿cambiar qué? "Una sola parte de la funcionalidad proporcionada por el software" = Unidad básica
Conclusión
El principio de responsabilidad única funciona en unidades básicas -> funciona a bajo nivel
La separación de preocupaciones funciona tanto a niveles altos como bajos
SRP y SoC trabajan juntos para separar preocupaciones. Son
exactamente iguales a bajo nivel
Dado que ninguna de las respuestas anteriores cita a Robert Martin, quien creó el principio de responsabilidad única , creo que aquí se necesita una respuesta más autorizada.
La inspiración de Martin para el SRP provino de David Parnas, Edsger Dijkstra (quien acuñó el término Separación de preocupaciones ) y Larry Constantine (quien acuñó los términos Acoplamiento y Cohesión ). Martin consolidó sus ideas en el SRP.
Otra redacción del principio de responsabilidad única es:
Reúna las cosas que cambian por las mismas razones. Separe aquellas cosas que cambian por diferentes razones.
Si piensa en esto, se dará cuenta de que esta es solo otra forma de definir la cohesión y el acoplamiento. Queremos aumentar la cohesión entre las cosas que cambian por las mismas razones, y queremos disminuir el acoplamiento entre aquellas cosas que cambian por diferentes razones.
Sin embargo, al pensar en este principio, recuerde que las razones del cambio son las personas . Son las personas las que solicitan cambios. Y no querrás confundir a esas personas, ni a ti mismo, mezclando el código que a muchas personas diferentes les importa por diferentes razones.
Con respecto a la pregunta original, la pequeña diferencia entre el SRP y el SoC es que Martin refinó el término preocupaciones para referirse a las personas .
La separación de preocupaciones es un proceso; el principio de responsabilidad única es una filosofía de diseño / arquitectura. No son completamente inconexos, pero tienen diferentes propósitos.
SRP y SOC trabajan en diferentes niveles de abstracción. El propósito es en ambos casos reducir el acoplamiento y fortalecer la cohesión. Si bien SRP funciona más a nivel de objeto, SOC también puede funcionar en la implementación de nivel de función. Una función puede ser implementada por un objeto pero también por varios objetos. Por tanto, el acoplamiento y la cohesión de ambos principios pueden diferir.
Traté de hacer una comparación entre la separación de preocupaciones (SoC) y el principio de responsabilidad única (SRP).
Diferencias
El SRP está a nivel de clase, pero el SoC está en cada programa de computadora, abstracción ... o en ocasiones a nivel arquitectónico.
El SRP trata sobre la calidad de (cómo no qué) dividir su dominio en clases cohesivas que tienen una sola responsabilidad (una razón para cambiar). Por otro lado, SoC es un principio de diseño para separar un contexto en distintas secciones, de modo que cada sección aborda una preocupación separada (qué no cómo), ya que hay muchas herramientas (por ejemplo, clases, funciones, módulos, paquetes,. ..) para alcanzar este objetivo en diferentes niveles.
El concepto de SRP se basa en la cohesión (alta cohesión), mientras que SoC se acerca a la Molecularidad, divide y vencerás (D&C), ... en cada nivel de abstracción.
SoC es un buen principio de diseño para hacer frente a la complejidad, como la abstracción, mientras que para llegar a clases responsables únicas puede utilizar el principio SoC como una gran solución. Como, una forma de saber que una clase tiene más de una responsabilidad es si puede extraer otra responsabilidad (preocupación) de esa clase.
Similitudes
Responder:
Separación de preocupaciones (SoC) es un término más versátil: se puede aplicar a nivel del sistema o en niveles inferiores, como clases (o incluso los métodos dentro de una clase)
El Principio de Responsabilidad Única (SRP) se usa para discutir SoC en los niveles inferiores, por ejemplo, en una clase.
Formas de pensarlo:
En el nivel bajo, SoC y SRP son sinónimos. Entonces, podría decir que SRP es un término redundante, o que SoC solo debe usarse para discutir el nivel del sistema
Dado (1), el término SoC es algo ambiguo. Necesita contexto para saber si la discusión es sobre SoC de alto nivel o sobre SoC de nivel inferior
Para recordar que SRP es el término solo para niveles inferiores, piense en esto: en el lenguaje cotidiano, una "responsabilidad" suele ser algo bien definido que puede vincularse a un código específico, mientras que las "preocupaciones" suelen ser un poco vagas y pueden abarcan un montón de cosas relacionadas, razón por la cual SoC es más natural para discutir el nivel del sistema que SRP
En cierto sentido, SoC es un requisito / principio más fuerte que SRP porque se aplica a nivel del sistema, y para que se logre realmente a nivel del sistema también debe utilizarse en el desarrollo de los componentes del sistema. Es decir, un nivel alto de SoC implica un SoC / SRP decente en los niveles inferiores, pero lo contrario no es cierto, es decir, un SoC / SRP de nivel inferior no implica un SoC ni nada en absoluto para el siguiente nivel superior, sin importar el que abarca el sistema. Para ver un ejemplo de SoC / SRP que se logra a nivel de método, pero luego se viola a nivel de clase, consulte esta publicación del blog de Artur Trosin .
Separación de intereses
El principio de Separación de preocupaciones (SOC) establece que un artefacto de código debe permitirle a uno enfocar su atención en un cierto aspecto. Un artefacto de código puede ser cualquier cosa, desde una función específica, hasta una clase, o un paquete completo, o incluso una aplicación completa. El principio SOC se puede aplicar a todos los niveles arquitectónicos de las aplicaciones. Un ejemplo de una arquitectura en la que se aplica SOC es una arquitectura en capas.
Principio de responsabilidad única
El Principio de Responsabilidad Única (SRP) establece que "Un módulo debe tener una, y sólo una, razón para cambiar" (Arquitectura limpia, Martin, p. 62). El SRP se aplica al nivel de módulo y al aplicar el SRP uno debe centrarse en la razón del cambio.
Conclusión
El principio SOC establece que un artefacto de código debe permitirle a uno enfocar su atención en un cierto aspecto. El SRP hace esto concreto al afirmar que a nivel de módulo debemos centrar nuestra atención en la razón del cambio. Por tanto, el SRP es un SOC.
PS Para que esté completo: el principio común de cierre
El Principio Común de Cierre (CCP) es una reformulación del SRP a un nivel aún más alto, el nivel del componente. El CCP establece que las clases que cambian por las mismas razones y al mismo tiempo deben agruparse en los mismos componentes (Arquitectura limpia, p. 105). El PCCh es otro ejemplo de un SOC.