Princípio de responsabilidade única: uma classe, apenas uma razão que causa sua mudança.
Por que o princípio único de responsabilidade é necessário?
Se uma classe tiver vários motivos para modificá -la, modificar uma função poderá causar erros a outras funções, por isso é melhor ter apenas uma responsabilidade por uma classe. Mas ainda é difícil de alcançar em aplicações práticas, por isso só podemos fazer o possível para cumprir esse princípio.
Às vezes, os desenvolvedores terão alguns problemas ao projetar interfaces, como as propriedades do usuário e o comportamento do usuário que estão sendo declarados em uma interface. Isso faz com que o objeto de negócios e a lógica de negócios sejam reunidos, o que faz com que a interface tenha duas responsabilidades. As responsabilidades da interface não são claras e, de acordo com a definição de SRP, viola o princípio das responsabilidades únicas da interface.
Aqui está um exemplo:
pacote com.loulijun.chapter1; interface pública iTutu {// altura void setshengao (altura dupla); duplo getshengao (); // Peso vazio de coleta (peso duplo); duplo gettizhong (); // coma chifan booleano (faminto booleano); // na Internet Boolean Shangwang (booleano bobo); }O exemplo acima tem esse problema. A altura e o peso pertencem ao objeto de negócios, e o método correspondente é principalmente responsável pelos atributos do usuário. Comer e navegar na Internet são a lógica de negócios correspondente, que é principalmente responsável pelo comportamento do usuário. Mas isso dará às pessoas a sensação de que elas não sabem o que essa interface está fazendo, as responsabilidades não são claras e vários problemas também serão causados durante a manutenção posterior.
Solução: o princípio da responsabilidade única, dividir essa interface em duas interfaces com diferentes responsabilidades.
Itutubo.java: responsável pelos atributos de Tutu (Tutu, se for um nome pessoal)
pacote com.loulijun.chapter1; /*** BO: objeto de negócios, objeto de negócios* responsável pelos atributos do usuário* @Author Administrator**/interface pública iTutubo {// altura void setshengao (altura dupla); duplo getshengao (); // Peso vazio de coleta (peso duplo); duplo gettizhong (); }Itutubl.java: responsável por colocar
pacote com.loulijun.chapter1; /*** BL: lógica de negócios, lógica de negócios* Responsável pelo comportamento do usuário* @Author Administrator**/interface pública Itutubl {// Coma uma refeição booleana chifan (fome booleana); // entretenimento booleano Shangwang (booleano bobo); }Isso realiza a única responsabilidade da interface. Então, ao implementar uma interface, existem duas classes diferentes
Tutubo.java
pacote com.loulijun.chapter1; classe pública Tutubo implementa o iTutubo {private dupla altura; peso duplo privado; @Override public Double getshengao () {return Hight; } @Override public duplo gettizhong () {return weight; } @Override public void setShengao (altura dupla) {this.Height = Height; } @Override public void Settizhong (peso duplo) {this.weight = peso; }}Tutubl.java
pacote com.loulijun.chapter1; classe pública tutublic implementa Itutubl {@Override public boolean Chifan (Boolean Hungry) {if (Hungry) {System.out.println ("Vá para ter um pote quente ..."); retornar true; } retornar false; } @Override public boolean Shangwang (booleano bobo) {if (bobo) {System.out.println ("So Boring, vá para a Internet ..."); retornar true; } retornar false; }}Isso deixa claro. Quando você precisa modificar os atributos do usuário, você só precisa modificar a interface Itutubo, que afetará apenas a classe Tutubo e não afetará outras classes.
Resumir:
1. A situação real é que muitas vezes não podemos prever a "causa da mudança" com antecedência, para que possamos construir apenas nossa interface com base na experiência e tentar garantir que uma interface tenha apenas uma responsabilidade. O que estamos falando aqui são interfaces. As classes podem herdar e implementar várias interfaces, dificultando a obtenção de uma única responsabilidade.
2. Quando as aulas que escrevi antes tiveram várias razões para a mudança, é melhor refatorá -la.
No entanto, há um problema com o princípio de usar a única responsabilidade. Não existe um padrão de divisão claro para "responsabilidades". Se as responsabilidades forem divididas muito detalhadas, isso levará a um aumento acentuado no número de interfaces e classes de implementação, o que aumentará a complexidade e reduzirá a manutenção do código. Portanto, ao usar essa responsabilidade, também devemos analisar a situação específica. A sugestão é que a interface deve adotar o princípio de responsabilidade única e realizar o princípio de responsabilidade única o máximo possível no design da classe. É melhor causar mudanças em uma classe se um motivo for causado.