Buscamos por el mundo online para así regalarte la respuesta a tu duda, si continúas con inquietudes puedes dejar la pregunta y contestaremos con gusto, porque estamos para ayudarte.
Solución:
La forma más efectiva de romper aplicaciones es crear clases GOD. Esas son clases que llevan un registro de mucha información y tienen varias responsabilidades. Lo más probable es que un cambio de código afecte a otras partes de la clase y, por lo tanto, indirectamente a todas las demás clases que lo utilizan. Eso, a su vez, conduce a un problema de mantenimiento aún mayor, ya que nadie se atreve a hacer ningún cambio más que agregarle nuevas funciones.
El siguiente ejemplo es una clase de TypeScript que define un Personesta clase no debe incluir la validación de correo electrónico porque eso no está relacionado 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 Persona y creando una nueva Email clase 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 sola responsabilidad hace que sea más fácil ver de forma predeterminada qué hace y cómo se puede ampliar/mejorar.
Echa un vistazo a la descripción sólida.
A menos que pida 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, lo que también se conoce como Alta Cohesión.
Las clases a menudo no comienzan con Low Cohesion, pero generalmente después de varios lanzamientos y diferentes desarrolladores que las agregan, de repente notará que se convirtió en una clase de monstruo o Dios, como algunos la llaman. Entonces la clase debe ser refactorizada.
Es difícil pensar en un buen ejemplo, pero uno que se me ocurre 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 orquestar la llamada a packageProcess() en ellas. Bueno, resultó que todos agregaron 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 la etapa. La clase manager ya no tenía una Responsabilidad Única, sino que también era responsable de hacer llamadas a las etapas para cambios de configuración: así la Cohesión se había reducido.
Terminamos teniendo que refactorizar la clase de gerente, eliminando toda la configuración del escenario y colocándola en una fábrica, dejando así que el gerente hiciera lo que estaba destinado a hacer.
Una clase debe tener una sola razón para cambiar.
Este principio establece que si tenemos 2 razones para cambiar 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 puedan trabajar en el mismo código por dos razones diferentes. Cada uno tendrá que desplegar su solución, lo que en el caso de un lenguaje compilado (como C++, C# o Java), puede dar lugar a módulos incompatibles con otros equipos u otras partes de la aplicación.
Este principio está íntimamente relacionado con los conceptos de acoplamiento y cohesión. El acoplamiento se refiere a qué tan inextricablemente vinculados están los diferentes aspectos de una aplicación, mientras que la cohesión se refiere a qué tan estrechamente relacionados pueden estar los contenidos de una clase o paquete en particular. Todos los contenidos de una sola clase están estrechamente relacionados entre sí, ya que la clase en sí misma es un [single unit][1] que debe usarse por completo o no usarse en absoluto.
Mi blog post sobre esto:
http://javaexplorer03.blogspot.in/2016/12/single-responsibility-principle.html
Si conservas alguna vacilación y capacidad de avanzar nuestro tutorial eres capaz de ejecutar una crítica y con deseo lo leeremos.