oop - software - solid en programación

¿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

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

Un ejemplo típico podría ser una clase EmailSender:

• esto solo debería tratar de enviar un correo electrónico.
• 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 hay un artículo sobre esto.

Answer 2

La forma más efectiva de romper aplicaciones para crear clases de 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 de TypeScript que define una Persona, esta clase no debe incluir validación de correo electrónico porque no está relacionada con el comportamiento de una 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 eliminando la responsabilidad de la validación de correo electrónico de la clase Person y creando 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 tenga una responsabilidad única hace que sea más fácil ver por defecto y qué puede hacer para ampliarlo / mejorarlo.

Answer 3

Mira la descripción de Solid .

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

La responsabilidad única es el concepto de una Clase que hace una cosa específica (responsabilidad) y no trata de 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 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 de etapa y poniéndola en una fábrica, dejando al administrador hacer lo que se pretendía hacer.

Answer 4

Una clase debe tener solo una razón 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 publica sobre esto:

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