separation of concerns - single - Diferencia entre el Principio de Responsabilidad Individual y la Separación de Preocupaciones
solid dip (10)
Principio de responsabilidad única (SRP): otorgue a cada clase una sola razón para cambiar; y "Motivo de cambio" == "responsabilidad". En el ejemplo: la clase de factura no tiene la responsabilidad de imprimirse.
Separación de preocupaciones (desde 1974). Preocupación == característica del sistema. Cuidando cada una de las inquietudes: para cada preocupación, otras preocupaciones son irrelevantes. Esconder la implementación del comportamiento.
Desde here .
¿Cuál es la diferencia entre el Principio de Responsabilidad Individual y la Separación de Preocupaciones?
El Principio de Responsabilidad Individual y la Separación de Preocupaciones son realmente lo mismo.
Seguro que puedes empantanarte en una discusión académica tratando de descubrir algún tipo de diferencia entre los dos, pero ¿por qué? Para todos los efectos, describen la misma cosa. El mayor problema es que las personas se interesan tanto por saber exactamente qué es "preocupación" y "responsabilidad", que quizás se pierdan la importante idea detrás de SRP y SoC.
Esa idea es simplemente dividir su base de código en partes aisladas ligeramente acopladas. Esto permite que múltiples desarrolladores trabajen en diferentes partes sin afectarse mutuamente, sino que también permite que un único 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. La base de código se divide en modelos, vistas y controladores aislados. De esta forma, la modificación de una vista se puede hacer independientemente de un modelo. Dos dos no están horriblemente entrelazados.
En un nivel inferior, esto debería aplicarse a las clases también. En lugar de poner docenas de métodos en una sola clase, divide el código en varios. Por las mismas razones.
También 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 es necesario (leer: no puede / no debería) seguirlo religiosamente hasta el 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.
En mi opinión, el Principio de Responsabilidad Individual es una de las herramientas / modismos para lograr la Separación de Preocupaciones.
Intenté hacer una comparación entre Separación de preocupaciones (SoC) y Principio de responsabilidad única (SRP).
Diferencias
El SRP está en el nivel de clase, pero SoC está en cada programa de computadora, abstracción ... o a veces nivel arquitectónico.
El SRP trata de 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, etc.). ..) para alcanzar este objetivo en diferentes niveles.
El concepto de SRP se basa en la cohesión (alta cohesión), mientras que SoC está cerca de la Molecularity, divide y vencerás (D y 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 individuales responsables 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
- Después de aplicar cada uno de estos principios, su contexto se vuelve más reutilizable, sostenible, robusto, legible, ...
La separación de preocupaciones es un proceso; el Principio de Responsabilidad Individual es una filosofía de diseño / arquitectura. No son completamente disjuntos, pero sirven para diferentes propósitos.
Responsabilidad única establece que un Objeto sea responsable de una sola unidad de trabajo.
Seperation of Concerns establece que las aplicaciones se deben dividir en módulos cuyas funcionalidades se superpongan lo menos posible.
Resultados finales similares ... aplicaciones ligeramente diferentes.
SRP y SOC trabajan en diferentes niveles de abstracción. El objetivo es en ambos casos reducir el acoplamiento y fortalecer la cohesión. Si bien SRP funciona más en un nivel de objeto, SOC también puede funcionar en la implementación del nivel de función. Una función puede ser implementada por un objeto pero también por varios objetos. Por lo tanto, el acoplamiento y la cohesión de ambos principios pueden diferir.
Similar pero: SoC está relacionado con las preocupaciones: para descomponer un problema complejo en varias preocupaciones, SRP tiene solo una responsabilidad.
Separación de la preocupación frente al 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 funcionalidad lo menos posible. Una preocupación es cualquier 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 responsabilidad única, y todos sus servicios deben estar estrechamente alineados con esa responsabilidad. En algún nivel, la cohesión se considera sinónimo de SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle
Separación de preocupaciones (SoC). Divida su aplicación en características distintas con la menor superposición posible en la funcionalidad. (Microsoft).
"Preocupación" = "característica distinta" = "sección distinta"
"Preocupación" funciona tanto en niveles altos como bajos
El principio de responsabilidad única establece que cada módulo o clase debe tener responsabilidad sobre una parte única 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 provista por el software" = Unidad Básica
Conclusión
Principio de Responsabilidad Individual funciona en unidades básicas -> funciona a bajo nivel
Separation of Concerns funciona tanto en niveles altos como bajos
SRP y SoC trabajan juntos para la separación de preocupaciones. Son
exactamente lo mismo en el bajo nivel