Principe de responsabilité unique: une classe, une seule raison qui provoque son changement.
Pourquoi le principe de responsabilité unique est-il nécessaire?
Si une classe a plusieurs raisons de le modifier, la modification d'une fonction peut entraîner des bogues à d'autres fonctions, il est donc préférable d'avoir une seule responsabilité pour une classe. Mais il est toujours difficile de réaliser dans des applications pratiques, nous ne pouvons donc faire de notre mieux pour nous conformer à ce principe.
Parfois, les développeurs auront des problèmes lors de la conception d'interfaces, telles que les propriétés de l'utilisateur et le comportement de l'utilisateur déclaré dans une interface. Cela entraîne la mise en place de l'objet commercial et de la logique commerciale, ce qui fait que l'interface a deux responsabilités. Les responsabilités d'interface ne sont pas claires et, selon la définition de SRP, elle viole le principe des responsabilités uniques de l'interface.
Voici un exemple:
Package com.loulijun.chapter1; Interface publique itutu {// HEUGHT VOID SetShengao (double hauteur); double getShengao (); // Poids vide Settizhong (double poids); double gettizhong (); // Mangez Boolean Chifan (Boolean Hungry); // sur Internet Boolean Shangwang (idiot booléen); }L'exemple ci-dessus a ce problème. La taille et le poids appartiennent à l'objet métier, et la méthode correspondante est principalement responsable des attributs de l'utilisateur. Manger et surfer sur Internet sont la logique commerciale correspondante, qui est principalement responsable du comportement de l'utilisateur. Mais cela donnera aux gens le sentiment qu'ils ne savent pas ce que fait cette interface, les responsabilités ne sont pas claires et divers problèmes seront également causés lors de la maintenance ultérieure.
Solution: Le principe de la responsabilité unique, divise cette interface en deux interfaces avec différentes responsabilités.
Itubo.java: responsable des attributs de Tutu (Tutu, s'il s'agit d'un nom personnel)
Package com.loulijun.chapter1; / ** * bo: objet métier, objet métier * responsable des attributs de l'utilisateur * @Author Administrator * * / interface publique itubo {// height void SetShengao (double hauteur); double getShengao (); // Poids vide Settizhong (double poids); double gettizhong (); }Itublis
Package com.loulijun.chapter1; / ** * BL: Logique métier, logique métier * responsable du comportement des utilisateurs * @Author Administrator * * / interface publique itubl {// manger un repas booléen Chifan (booléen hungry); // Entertainment Boolean Shangwang (idiot booléen); }Cela réalise la responsabilité unique de l'interface. Ensuite, lors de l'implémentation d'une interface, il existe deux classes différentes
Tutubo.java
Package com.loulijun.chapter1; La classe publique tutubo implémente itutubo {double hauteur privée; double poids privé; @Override public double getShengao () {return height; } @Override public double gettizhong () {return poids; } @Override public void SetShengao (double hauteur) {this.height = height; } @Override public void Settizhong (double poids) {this.weight = poids; }}TUTUBL.JAVA
Package com.loulijun.chapter1; La classe publique TUTUBL implémente ituber {@Override public boolean Chifan (booléen hungry) {if (Hungry) {System.out.println ("aller pour avoir une hot pot ..."); Retour Vrai; } return false; } @Override public boolean shangwang (booléen idiot) {if (idiot) {System.out.println ("So ennuyeux, allez sur Internet ..."); Retour Vrai; } return false; }}Cela le rend clair. Lorsque vous devez modifier les attributs de l'utilisateur, il vous suffit de modifier l'interface itubo, qui n'affectera que la classe tutubo et n'affectera pas d'autres classes.
Résumer:
1. La situation réelle est que plusieurs fois, nous ne pouvons pas prévoir la "cause du changement" à l'avance, nous ne pouvons donc construire notre interface en fonction de l'expérience et essayer de garantir qu'une seule interface n'a qu'une seule responsabilité. Ce dont nous parlons ici, ce sont les interfaces. Les classes peuvent hériter et mettre en œuvre plusieurs interfaces, ce qui rend plus difficile d'atteindre une seule responsabilité.
2. Lorsque les cours que j'ai écrits auparavant ont eu plusieurs raisons pour le changement, il est préférable de le refactor.
Cependant, il y a un problème avec le principe d'utilisation de la responsabilité unique. Il n'y a pas de norme de division claire pour les "responsabilités". Si les responsabilités sont divisées trop détaillées, cela entraînera une forte augmentation du nombre d'interfaces et de classes de mise en œuvre, ce qui augmentera la complexité et réduira la maintenabilité du code. Par conséquent, lorsque vous utilisez cette responsabilité, nous devons également analyser la situation spécifique. La suggestion est que l'interface doit adopter le principe de responsabilité unique et réaliser autant que possible le principe de responsabilité unique dans la conception de la classe. Il est préférable de provoquer des changements dans une classe si l'une des raisons est causée.