La définition principale du principe de responsabilité unique dit qu'une classe ne devrait avoir qu'une seule raison de changer. Décomposons cette déclaration pour une meilleure compréhension.
Supposons que nous ayons une classe qui manipule le texte que nous lui transmettons, le principe de responsabilité unique stipule que la classe que nous créons ne devrait être responsable que de la manipulation du texte, et que toute autre action qu'elle effectue ne devrait pas en faire partie. la classe.
Prenons un exemple d'une telle classe et voyons comment nous pouvons la refactoriser :
class TextManipulator { text: string; constructor(text: string) { this.text = text; } appendText(newText: string) { return this.text.concat(newText); } findAndReplace(word: string, replacementWord: string) { if (this.text.includes(word)) { this.text.replace(word, replacementWord); } return this.text; } printText() { console.log("The text is ", this.text); } }
Dans le code ci-dessus, on peut voir que la classe effectue également l'action d'impression. Cela rompt le principe de responsabilité unique. Nous pouvons refactoriser le code en créant deux nouvelles classes
class TextManipulator { private text: string; constructor(text: string) { this.text = text; } appendText(newText: string) { return this.text.concat(newText); } findAndReplace(word: string, replacementWord: string) { if (this.text.includes(word)) { this.text.replace(word, replacementWord); } return this.text; } getText() { return this.text; } } class PrintText { formattedText: TextManipulator; constructor(formattedText: TextManipulator) { this.formattedText = formattedText; } printText() { console.log("The text is ", this.formattedText.getText()); } }
Dans le code refactorisé, nous avons deux classes distinctes qui effectuent des actions distinctes.
Avec le principe de responsabilité unique en place, nous pouvons réaliser ce qui suit :-
L'astuce pour mettre en œuvre le principe de responsabilité unique est de savoir quelle est la responsabilité unique de notre classe. Cependant, chaque développeur a sa vision de la responsabilité de classe, et comme nous n'avons aucune instruction sur la façon de la mettre en œuvre, il ne nous reste que notre propre interprétation.
Il peut y avoir des cas où nous séparons deux classes qui font en fait la même chose du point de vue commercial ou architectural. Cela peut créer un code plus compliqué avec les deux classes étroitement couplées les unes aux autres, et réduisant ainsi le seul objectif des principes SOLIDE
La clé est de ne pas trop réfléchir lors de la création de nouvelles classes
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!