En Java, Des principes SOLIDES sont une approche orientée objet appliquée à la conception de structures logicielles. Il est conceptualisé par Robert C.Martin (également connu sous le nom d'Oncle Bob). Ces cinq principes ont changé le monde de la programmation orientée objet, ainsi que la manière d'écrire des logiciels. Cela garantit également que le logiciel est modulaire, facile à comprendre, à déboguer et à refactoriser. Dans cette section, nous discuterons Principes SOLID en Java avec un bon exemple .
tuple python trié
Le mot SOLIDE acronyme pour :
- Principe de responsabilité unique (SRP)
- Principe ouvert-fermé (OCP)
- Principe de substitution de Liskov (LSP)
- Principe de ségrégation d'interface (ISP)
- Principe d'inversion de dépendance (DIP)
Expliquons les principes un par un en détail.
Principe de responsabilité unique
Le principe de responsabilité unique stipule que chaque classe Java doit exécuter une seule fonctionnalité . Implémentation de plusieurs fonctionnalités dans une seule classe, mashup le code et si une modification est nécessaire, peut affecter l'ensemble de la classe. Il précise le code et le code peut être facilement maintenu. Comprenons le principe de responsabilité unique à travers un exemple.
Supposer, Étudiant est une classe ayant trois méthodes à savoir printDetails(), calculatePercentage(), et addStudent(). Par conséquent, la classe Étudiant a trois responsabilités : imprimer les détails des étudiants, calculer les pourcentages et base de données. En utilisant le principe de responsabilité unique, nous pouvons séparer ces fonctionnalités en trois classes distinctes pour atteindre l'objectif du principe.
Étudiant.java
public class Student { public void printDetails(); { //functionality of the method } pubic void calculatePercentage(); { //functionality of the method } public void addStudent(); { //functionality of the method } } L'extrait de code ci-dessus viole le principe de responsabilité unique. Pour atteindre l’objectif du principe, nous devons implémenter une classe distincte qui n’exécute qu’une seule fonctionnalité.
Étudiant.java
public class Student { public void addStudent(); { //functionality of the method } } PrintStudentDetails.java
public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } Pourcentage.java
public class Percentage { public void calculatePercentage(); { //functionality of the method } } Nous avons donc atteint l’objectif du principe de responsabilité unique en séparant les fonctionnalités en trois classes distinctes.
Principe ouvert-fermé
L'application ou le module entité les méthodes, fonctions, variables, etc. Le principe ouvert-fermé stipule que selon les nouvelles exigences le module doit être ouvert pour extension mais fermé pour modification. L'extension nous permet d'implémenter de nouvelles fonctionnalités dans le module. Comprenons le principe à travers un exemple.
Supposer, Informations sur le véhicule est une classe et elle a la méthode numéro de véhicule() qui renvoie le numéro du véhicule.
VehicleInfo.java
public class VehicleInfo { public double vehicleNumber(Vehicle vcl) { if (vcl instanceof Car) { return vcl.getNumber(); if (vcl instanceof Bike) { return vcl.getNumber(); } } Si nous voulons ajouter une autre sous-classe nommée Truck, nous ajoutons simplement une autre instruction if qui viole le principe ouvert-fermé. La seule façon d'ajouter la sous-classe et d'atteindre l'objectif de principe en remplaçant la numéro de véhicule() méthode, comme nous l’avons montré ci-dessous.
VehicleInfo.java
public class VehicleInfo { public double vehicleNumber() { //functionality } } public class Car extends VehicleInfo { public double vehicleNumber() { return this.getValue(); } public class Car extends Truck { public double vehicleNumber() { return this.getValue(); } De même, nous pouvons ajouter plus de véhicules en créant une autre sous-classe s'étendant à partir de la classe de véhicule. cette approche n’affecterait pas l’application existante.
Principe de substitution de Liskov
Le principe de substitution de Liskov (LSP) a été introduit par Barbara Liskov . Cela s'applique à l'héritage de telle manière que le les classes dérivées doivent être complètement substituables à leurs classes de base . En d’autres termes, si la classe A est un sous-type de la classe B, alors nous devrions pouvoir remplacer B par A sans interrompre le comportement du programme.
écart type des pandas
Il étend le principe d'ouverture-fermeture et se concentre également sur le comportement d'une superclasse et de ses sous-types. Nous devrions concevoir les classes de manière à préserver la propriété, sauf si nous avons de bonnes raisons de faire autrement. Comprenons le principe à travers un exemple.
Étudiant.java
public class Student { private double height; private double weight; public void setHeight(double h) { height = h; } public void setWeight(double w) { weight= w; } ... } public class StudentBMI extends Student { public void setHeight(double h) { super.setHeight(h); super.setWeight(w); } public void setWeight(double h) { super.setHeight(h); super.setWeight(w); } } Les classes ci-dessus ont violé le principe de substitution de Liskov car la classe StudentBMI a des contraintes supplémentaires, c'est-à-dire une taille et un poids qui doivent être les mêmes. Par conséquent, la classe Student (classe de base) ne peut pas être remplacée par la classe StudentBMI (classe dérivée).
Par conséquent, le remplacement de la classe Student par la classe StudentBMI peut entraîner un comportement inattendu.
Principe de séparation des interfaces
Le principe stipule que les plus grandes interfaces se divisent en plus petites. Parce que les classes d’implémentation utilisent uniquement les méthodes requises. Nous ne devons pas forcer le client à utiliser les méthodes qu’il ne souhaite pas utiliser.
L’objectif du principe de ségrégation des interfaces est similaire à celui du principe de responsabilité unique. Comprenons le principe à travers un exemple.
Supposons que nous ayons créé une interface nommée Conversion avoir trois méthodes intToDouble(), intToChar(), et charVersChaîne() .
public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } L'interface ci-dessus comporte trois méthodes. Si nous voulons utiliser uniquement une méthode intToChar(), nous n’avons pas le choix d’implémenter la méthode unique. Pour pallier le problème, le principe permet de diviser l'interface en trois interfaces distinctes.
public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } Nous pouvons désormais utiliser uniquement la méthode requise. Supposons que nous voulions convertir l'entier en double et le caractère en chaîne, nous n'utiliserons alors que les méthodes intVersDouble() et charToString().
public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } Principe d'inversion de dépendance
Le principe stipule que nous devons utiliser l'abstraction (classes et interfaces abstraites) au lieu d'implémentations concrètes. Les modules de haut niveau ne doivent pas dépendre du module de bas niveau mais les deux doivent dépendre de l'abstraction. Parce que l'abstraction ne dépend pas du détail mais le détail dépend de l'abstraction. Cela découple le logiciel. Comprenons le principe à travers un exemple.
public class WindowsMachine { //functionality } Cela vaut la peine, si nous n'avons pas de clavier et de souris pour travailler sous Windows. Pour résoudre ce problème, nous créons un constructeur de classe et ajoutons les instances du clavier et du moniteur. Après avoir ajouté les instances, la classe ressemble à ceci :
public class WindowsMachine { public final keyboard; public final monitor; public WindowsMachine() { monitor = new monitor(); //instance of monitor class keyboard = new keyboard(); //instance of keyboard class } } Nous pouvons désormais travailler sur la machine Windows à l’aide d’un clavier et d’une souris. Mais nous sommes toujours confrontés au problème. Parce que nous avons étroitement couplé les trois classes en utilisant le nouveau mot-clé. Il est difficile de tester la machine Windows de classe.
Pour rendre le code faiblement couplé, nous dissocions WindowsMachine du clavier en utilisant l'interface Keyboard et ce mot-clé.
Unité arithmétique et logique
Clavier.java
public interface Keyboard { //functionality } WindowsMachine.java
public class WindowsMachine { private final Keyboard keyboard; private final Monitor monitor; public WindowsMachine(Keyboard keyboard, Monitor monitor) { this.keyboard = keyboard; this.monitor = monitor; } } Dans le code ci-dessus, nous avons utilisé l'injection de dépendances pour ajouter la dépendance clavier dans la classe WindowsMachine. Nous avons donc découplé les classes.
Pourquoi devrions-nous utiliser les principes SOLID ?
- Il réduit les dépendances afin qu'un bloc de code puisse être modifié sans affecter les autres blocs de code.
- Les principes destinés à rendre la conception plus facile et compréhensible.
- En utilisant ces principes, le système est maintenable, testable, évolutif et réutilisable.
- Cela évite la mauvaise conception du logiciel.
La prochaine fois que vous concevrez un logiciel, gardez ces cinq principes à l’esprit. En appliquant ces principes, le code sera beaucoup plus clair, testable et extensible.