¿Cuál es la diferencia entre el principio de responsabilidad única y la separación de preocupaciones?Diferencia entre el principio de responsabilidad única y la separación de preocupaciones
Respuesta
Responsabilidad solo principio (SRP) - dar a cada clase sólo una de las razones para el cambio ; y "Motivo de cambio" == "responsabilidad". En el ejemplo: la clase de la factura no tiene una responsabilidad para imprimirse.
Separación de preocupaciones (desde 1974). Preocupación == característica del sistema. Tomando cuidado de cada una de las preocupaciones: por cada una preocupación, otras preocupaciones son irrelevantes. Ocultación de la implementación del comportamiento .
De here.
Separation of Concern vs Single Responsibility Principle (SoC vs SRP)
Desde el artículo enlazado:
separación de las preocupaciones (SoC) - es el proceso de descomposición de un programa de ordenador en características distintas que se solapan en la 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
Responsabilidad solo principio (SRP) - cada objeto debe tener un único responsable, y que todos sus servicios debe ser alineado estrechamente con esa responsabilidad. En algún nivel, la cohesión se considera sinónimo de SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle
con esta definición, ¿en qué nivel de cohesión se considera sinónimo de principio de responsabilidad única? Busqué que hay muchos niveles de cohesión (de bajo a alto): coincidente, lógico, temporal, de procedimiento y funcional. En esta explicación, ¿implica solamente "cohesión funcional"? – limonik
Responsabilidad única establece que un Objeto sea responsable de una sola unidad de trabajo.
Separation of Concerns indica que las aplicaciones se deben dividir en módulos cuyas funciones se superpongan lo menos posible.
Resultados finales similares ... aplicaciones ligeramente diferentes.
¿cuál es la diferencia entre el objeto y el módulo? Para mí, un módulo es una clase y un objeto es clase o una instancia de una clase – Rookian
Un módulo puede ser una pieza completa de funcionalidad similar en una aplicación ... compuesta de la interacción entre muchas clases (cada clase tiene una responsabilidad única) si sigues el patrón de responsabilidad única). –
En mi opinión, el Principio de Responsabilidad Individual es una de las herramientas/modismos para lograr la Separación de Preocupaciones.
¿Qué? Uno podría crear fácilmente una aplicación que tiene una funcionalidad que no se superpone (SRP) que contiene muchos objetos que no se preocupan por separado (! SOC). –
Pero es mucho más difícil imaginar un objeto que tiene múltiples responsabilidades y aún se adhiere al principio de separación de preocupaciones. En otras palabras, para lograr una separación real de las preocupaciones (en todos los niveles), un principio de responsabilidad única mejor observado – BostonLogan
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.
Similar pero: SoC está relacionado con las preocupaciones: para desglosar un problema complejo en varias preocupaciones, SRP tiene solo una responsabilidad.
El Principio de Responsabilidad Individual y la Separación de Preocupaciones son realmente la misma cosa.
Claro que puede empantanarse 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 la 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.
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.
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” = “rasgo distintivo” = “sección distinta”
“preocupación” funciona en ambos niveles altos y bajos
solo principio responsabilidad estados que cada módulo o clase debe tener responsabilidad sobre una parte única de la funcionalidad provista 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
Responsabilidad solo principio funciona en unidades básicas -> trabaja a bajo nivel
Separación of Concerns funciona tanto en niveles altos como bajos
SRP y SoC trabajan juntos para separati sobre las preocupaciones.Son
exactamente lo mismo en el nivel bajo
SRP también funciona en diferentes niveles. Usted tiene una responsabilidad más general a nivel de biblioteca, que a nivel de clase y más específica en el nivel de función. – Phil1970
Traté de hacer una comparación entre la separación de las preocupaciones (SoC) y Responsabilidad solo principio (SRP).
Diferencias
El SRP es a nivel de clase, pero SOC es en cada programa de ordenador, abstracción ... o el nivel de arquitectura veces.
El SRP trata sobre la calidad de (cómo no qué) la división de 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 conquista (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 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, fácil de mantener, robusto, fácil de leer, ....
- 1. ¿Cuándo viola SRP (principio de responsabilidad única)?
- 2. ¿Qué significa el principio de responsabilidad única para la validación
- 3. IFilterProvider y separación de preocupaciones
- 4. ¿Cómo aborda Clojure la separación de preocupaciones?
- 5. Separación de preocupaciones - DAO, DTO y BO
- 6. ¿Qué es la separación de preocupaciones?
- 7. ¿Puede un "modelo de dominio enriquecido" violar el principio de responsabilidad única?
- 8. ¿Cómo se relaciona el principio de responsabilidad única con el modelo de dominio anémico/rico?
- 9. Preocupaciones de separación con Linq To SQL y DTO
- 10. Cómo aplicar el principio de responsabilidad única a una clase de servicio
- 11. ¿Cómo usar el principio de responsabilidad única en servicios grandes de wcf?
- 12. ¿No es información experta/informativa que no se contradiga con el principio de responsabilidad única?
- 13. la implementación de múltiples interfaz de violar solo principio Responsabilidad
- 14. Ayuda para comprender el Principio de Responsabilidad Individual
- 15. ¿Cuán estrictamente sigue la arquitectura de n niveles y la separación de preocupaciones entre las capas en sus proyectos?
- 16. separación de las preocupaciones y el patrón Repositorio de Entity Framework 3.5
- 17. Marco de la entidad, las capas de aplicación y separación de las preocupaciones
- 18. Usando el principio de separación Command-Query en Controladores MVC
- 19. es obsoleto palabra la única diferencia entre fill_parent y match_parent
- 20. ¿Cómo evitar los modelos de dominio anémico y mantener la separación de las preocupaciones?
- 21. ¿Es este un ejemplo del Principio de Responsabilidad Individual?
- 22. ¿Qué es un ejemplo del Principio de Responsabilidad Individual?
- 23. ¿La adhesión estricta al Principio de Responsabilidad Individual viola la encapsulación?
- 24. Usando el "Principio de Responsabilidad Individual" obliga a mis contenedores a tener incubadoras públicas
- 25. .NET refactorización, SECO. herencia dual, acceso a datos y separación de preocupaciones
- 26. ¿La frecuencia de lanzamiento es la única diferencia real entre Agile y Waterfall?
- 27. Cómo dividir la responsabilidad entre LDAP y RDBMS
- 28. ¿Cómo construir ViewModel en MVVM para no violar el Principio de Responsabilidad Individual?
- 29. ¿Cuál es la diferencia entre la clave principal y la restricción de clave única?
- 30. Confundido sobre el Principio de Responsabilidad Individual en el siguiente ejemplo
Esto debe ser una tontería. Busque cada uno y lea las respuestas. Están muy vinculados y a menudo se debaten juntos. –
No veo ningún truco, ¿tiene uno en mente? Me gustaría votar para cerrar si puedes encontrar uno. –
Parece que no puedo encontrarlo, pero pensé que había respondido algo similar a esto hace unos meses. Algunas buenas respuestas están llegando, y parece que nadie está encontrando engañados, así que tal vez estoy loco. –