Principio de responsabilidad única: una clase, solo una razón que causa su cambio.
¿Por qué se necesita el principio de responsabilidad única?
Si una clase tiene múltiples razones para modificarla, entonces modificar una función puede causar errores a otras funciones, por lo que es mejor tener solo una responsabilidad para una clase. Pero todavía es difícil de lograr en aplicaciones prácticas, por lo que solo podemos hacer todo lo posible para cumplir con este principio.
A veces, los desarrolladores tendrán algunos problemas al diseñar interfaces, como las propiedades del usuario y el comportamiento del usuario que se declara en una interfaz. Esto hace que el objeto comercial y la lógica comercial se elaboren, lo que hace que la interfaz tenga dos responsabilidades. Las responsabilidades de la interfaz no están claras, y de acuerdo con la definición de SRP, viola el principio de responsabilidades únicas de la interfaz.
Aquí hay un ejemplo:
paquete com.loulijun.Capter1; interfaz pública itutu {// altura void setShengao (doble altura); doble getShengao (); // peso nulo settizhong (doble peso); doble gettizhong (); // comer chifan booleano (hambriento booleano); // en Internet boolean shangwang (boolean tonto); }El ejemplo anterior tiene este problema. La altura y el peso pertenecen al objeto comercial, y el método correspondiente es el principal responsable de los atributos del usuario. Comer y navegar por Internet es la lógica comercial correspondiente, que es principalmente responsable del comportamiento del usuario. Pero esto le dará a las personas la sensación de que no saben lo que está haciendo esta interfaz, las responsabilidades no están claras y también se causarán varios problemas durante el mantenimiento posterior.
Solución: El principio de responsabilidad única, divide esta interfaz en dos interfaces con diferentes responsabilidades.
Itutubo.java: responsable de los atributos de tutu (tutu, si es un nombre personal)
paquete com.loulijun.Capter1; /*** bo: objeto comercial, objeto comercial* responsable de los atributos del usuario* @author administrador**/interfaz public itutubo {// altura void setShengao (doble altura); doble getShengao (); // peso nulo settizhong (doble peso); doble gettizhong (); }Itutubl.java: responsable de colocar
paquete com.loulijun.Capter1; /*** BL: Lógica de negocios, Lógica de negocios* Responsable del comportamiento del usuario* @author Administrator**/Public Interface ITUTUBL {// Come una comida boolean Chifan (boolean hungry); // Entertainment Boolean Shangwang (Boolean Silly); }Esto se da cuenta de la responsabilidad única de la interfaz. Luego, al implementar una interfaz, hay dos clases diferentes
Tutubo.java
paquete com.loulijun.Capter1; clase pública Tutubo implementa iTutubo {Doble altura privada; doble peso privado; @Override public Double GetShengao () {return Height; } @Override public Double getTizhong () {return peso; } @Override public void setShengao (doble altura) {this.height = altura; } @Override public void settizhong (doble peso) {this.weight = weight; }}Tutubl.java
paquete com.loulijun.Capter1; Public Class Tutublement Implements Itutubl {@Override public boolean Chifan (boolean hungry) {if (hungry) {system.out.println ("ir a tener una olla caliente ..."); devolver verdadero; } return false; } @Override public boolean shangwang (boolean tonto) {if (tonto) {system.out.println ("tan aburrido, vaya a Internet ..."); devolver verdadero; } return false; }}Esto lo deja en claro. Cuando necesita modificar los atributos del usuario, solo necesita modificar la interfaz ITUTUBO, que solo afectará a la clase Tutubo y no afectará a otras clases.
Resumir:
1. La situación real es que muchas veces no podemos prever la "causa del cambio" de antemano, por lo que solo podemos construir nuestra interfaz en función de la experiencia y tratar de garantizar que una interfaz solo tenga una responsabilidad. De lo que estamos hablando aquí son las interfaces. Las clases pueden heredar e implementar múltiples interfaces, lo que hace que sea más difícil lograr una sola responsabilidad.
2. Cuando las clases que escribí antes han tenido múltiples razones para el cambio, es mejor refactorizarlo.
Sin embargo, existe un problema con el principio de usar la responsabilidad única. No existe un estándar de división claro para "responsabilidades". Si las responsabilidades se dividen demasiado detalladas, conducirá a un fuerte aumento en el número de interfaces y clases de implementación, lo que aumentará la complejidad y reducirá la capacidad de mantenimiento del código. Por lo tanto, al usar esta responsabilidad, también debemos analizar la situación específica. La sugerencia es que la interfaz debe adoptar el principio de responsabilidad única y darse cuenta del principio de responsabilidad única tanto como sea posible en el diseño de la clase. Es mejor causar cambios en una clase si se causa una razón.