¿Qué es un ejemplo del Principio de Responsabilidad Individual?

Question

¿Puede alguien darme un ejemplo del Principio de Responsabilidad Individual? Estoy tratando de entender lo que significa, en la práctica, que una clase tenga una sola responsabilidad ya que me temo que probablemente rompa esta regla a diario.

Answer 1

Compruebe hacia fuera el Solid description.

A menos que solicite algo más específico, será difícil ayudar más.

La responsabilidad individual es el concepto de una Clase que hace una cosa específica (responsabilidad) y no intenta hacer más de lo que debería, que también se conoce como Cohesión Alta.

Las clases no suelen comenzar con baja cohesión, pero normalmente después de varios lanzamientos y diferentes desarrolladores que se suman a ellas, de repente notarás que se convirtió en un monstruo o una clase de Dios como algunos lo llaman. Entonces la clase debe ser refactorizada.

Es difícil pensar en un buen ejemplo, pero uno en el que puedo pensar recientemente sería una clase que tenemos que maneja diferentes etapas de procesamiento de paquetes, un tipo de Chain of Responsibility. La intención inicial de esta clase era mantener una lista de etapas y orquestarlas llamando a packetProcess() sobre ellas. Bueno, terminó que todo el mundo agregó algo relacionado con las etapas de procesamiento (ya que la clase de administrador era un lugar fácil para acceder a las etapas) a esta clase de administrador, especialmente la configuración de escenario. La clase de administrador ya no tenía una sola responsabilidad, sino que también era responsable de realizar llamadas a las etapas para los cambios de configuración: por lo tanto, la Cohesión se había reducido.

Terminamos teniendo que refactorizar la clase de administrador, arrancando toda la configuración del escenario y poniéndolo en una fábrica, dejando al administrador hacer lo que estaba destinado a hacer.

Answer 2

La forma más efectiva de romper aplicaciones para crear clases GOD. Esas son clases que mantienen un registro de mucha información y tienen varias responsabilidades. Es probable que un cambio de código afecte a otras partes de la clase y, por lo tanto, indirectamente a todas las otras clases que lo utilizan. Esto, a su vez, lleva a un desorden de mantenimiento aún mayor, ya que nadie se atreve a hacer ningún cambio que no sea agregarle nuevas funcionalidades.

El siguiente ejemplo es una clase mecanografiado que define una persona, esta clase no debe incluir la validación de correo electrónico, ya que no está relacionada con un comportamiento persona:

class Person { 
    public name : string; 
    public surname : string; 
    public email : string; 
    constructor(name : string, surname : string, email : string){ 
     this.surname = surname; 
     this.name = name; 
     if(this.validateEmail(email)) { 
      this.email = email; 
     } 
     else { 
      throw new Error("Invalid email!"); 
     } 
    } 
    validateEmail(email : string) { 
     var re = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i; 
     return re.test(email); 
    } 
    greet() { 
     alert("Hi!"); 
    } 
} 

Podemos mejorar la clase anterior mediante la eliminación la responsabilidad de validación de correo electrónico de la clase Persona y la creación de una nueva clase de correo electrónico que tendrá esa responsabilidad:

class Email { 
    public email : string; 
    constructor(email : string){ 
     if(this.validateEmail(email)) { 
      this.email = email; 
     } 
     else { 
      throw new Error("Invalid email!"); 
     }   
    } 
    validateEmail(email : string) { 
     var re = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i; 
     return re.test(email); 
    } 
} 

class Person { 
    public name : string; 
    public surname : string; 
    public email : Email; 
    constructor(name : string, surname : string, email : Email){ 
     this.email = email; 
     this.name = name; 
     this.surname = surname; 
    } 
    greet() { 
     alert("Hi!"); 
    } 
} 

asegurarse de que una clase tiene un único respon La flexibilidad hace que sea por defecto también más fácil ver lo que hace y cómo puede ampliarlo/mejorarlo.

Answer 3

El Principio de Responsabilidad Individual (SRP) establece que una clase o un método solo deberían estar haciendo una cosa y no deberían estar haciendo nada relacionado. Una clase debe tener solo una razón para cambiar.

Un ejemplo típico podría una clase RemitenteDeCorreo:

• esto sólo debe lidiar con el envío de un correo electrónico a cabo.
• esto no debería ser responsable de cargar el contenido del correo electrónico desde la base de datos o incluso formatear el contenido del correo electrónico que se enviará.

Here es un artículo sobre esto.

Answer 4

Una clase solo debe tener un motivo para cambiar.

Este principio establece que si tenemos 2 razones para cambiar para una clase, tenemos que dividir la funcionalidad en dos clases. Cada clase manejará solo una responsabilidad y si en el futuro necesitamos hacer un cambio, lo haremos en la clase que lo maneja.

Si hay dos razones diferentes para cambiar, es concebible que dos equipos diferentes trabajen en el mismo código por dos razones diferentes. Cada uno tendrá que implementar su solución, que en el caso de un lenguaje compilado (como C++, C# o Java), puede conducir a módulos incompatibles con otros equipos u otras partes de la aplicación.

Este principio está estrechamente relacionado con los conceptos de acoplamiento y cohesión. El acoplamiento se refiere a la forma inextricablemente unida de los diferentes aspectos de una aplicación, mientras que la cohesión se refiere a cuán estrechamente relacionados están los contenidos de una clase o paquete en particular. Todos los contenidos de una sola clase están estrechamente unidos, ya que la clase en sí misma es una [unidad única] [1] que debe utilizarse por completo o no utilizarse en absoluto.

Mi blog el siguiente:

http://javaexplorer03.blogspot.in/2016/12/single-responsibility-principle.html