Je rencontre très souvent des développeurs qui n'ont pas entendu parler des principes de SOLID (nous en avons
parlé en détail ici . - Transl.) Ou de la programmation orientée objet (POO), ou entendu, mais ne les utilisez pas dans la pratique. Cet article décrit les avantages des principes de POO qui aident un développeur dans son travail quotidien. Certains d'entre eux sont bien connus, d'autres pas très bien, donc l'article sera utile pour les programmeurs débutants et expérimentés.
Nous vous rappelons: pour tous les lecteurs de «Habr» - une remise de 10 000 roubles lors de l'inscription à un cours Skillbox en utilisant le code promo «Habr».
Skillbox recommande: Le cours de formation en ligne pour les développeurs Java .
SEC (ne vous répétez pas)
Un principe assez simple, dont l'essence ressort clairement du titre: "Ne répétez pas". Pour le programmeur, cela signifie la nécessité d'éviter le code en double, ainsi que la possibilité d'utiliser l'abstraction dans le travail.
Si le code comporte deux sections répétitives, elles doivent être combinées en une seule méthode. Si une valeur codée en dur est utilisée plusieurs fois, il vaut la peine de la convertir en constante publique.
Cela est nécessaire pour simplifier le code et faciliter son support, ce qui est la tâche principale de la POO. La combinaison de l'union n'en vaut pas la peine, car le même code ne passera pas la vérification avec OrderId et SSN.
Encapsulation du changement
Les produits logiciels de la plupart des entreprises évoluent constamment. Donc, vous devez apporter des modifications au code, il doit être pris en charge. Vous pouvez vous simplifier la vie avec l'encapsulation. Cela permettra des tests et une maintenance plus efficaces de la base de code existante.
Voici un exemple .
Si vous écrivez en Java,
affectez par défaut des méthodes et des variables privées .
Le principe d'ouverture / de proximité
Ce principe peut être facilement rappelé en lisant la déclaration suivante: "Les entités logicielles (classes, modules, fonctions, etc.) doivent être ouvertes pour l'expansion, mais fermées pour le changement." En pratique, cela signifie qu'ils peuvent vous permettre de modifier leur comportement sans changer le code source.
Le principe est important lorsque les modifications du code source nécessitent une révision, des tests unitaires et d'autres procédures. Le code qui obéit au principe d'ouverture / de proximité ne change pas pendant l'expansion, donc il y a beaucoup moins de problèmes avec lui.
Voici un exemple de code qui viole ce principe.
Si vous devez y changer quelque chose, cela prendra beaucoup de temps, car vous devrez changer toutes les sections du code qui ont une connexion avec le fragment souhaité.
Soit dit en passant, l'ouverture-fermeture est l'un des principes de SOLID.
Principe de responsabilité unique (PRS)
Un autre principe de la suite SOLID. Il déclare qu '"il n'y a qu'une seule raison menant à un changement de classe". Une classe ne résout qu'un seul problème. Il peut avoir plusieurs méthodes, mais chacune d'elles n'est utilisée que pour résoudre un problème commun. Toutes les méthodes et propriétés ne doivent servir que cela.
La valeur de ce principe est qu'il affaiblit la connexion entre le composant logiciel individuel et le code. Si vous ajoutez plusieurs fonctionnalités à une classe, cela introduit une connexion entre les deux fonctions. Ainsi, si vous changez l'un d'eux, il y a une grande chance de gâcher le second, associé au premier. Et cela signifie une augmentation des cycles de test afin d'identifier à l'avance tous les problèmes.
Principe d'inversion de dépendance (DIP)
Ce qui précède est un exemple de code où l'AppManager dépend d'un EventLogWriter, qui à son tour est étroitement lié à l'AppManager. Si vous avez besoin d'une autre façon d'afficher une notification, que ce soit push, SMS ou e-mail, vous devez changer la classe AppManager.
Le problème peut être résolu en utilisant DIP. Ainsi, au lieu d'AppManager, nous demandons un EventLogWriter, qui sera introduit en utilisant le framework.
DIP vous permet de remplacer facilement des modules individuels par d'autres, en changeant le module de dépendance. Cela permet de changer un module sans affecter le reste.
Composition au lieu de l'héritage
Il y a deux façons principales de réutiliser du code - c'est l'héritage et la composition, et chacune a ses propres avantages et inconvénients. Le second est généralement préféré car il est plus flexible.
La composition vous permet de modifier le comportement d'une classe au moment de l'exécution en définissant ses propriétés. Lors de l'implémentation des interfaces, le polymorphisme est utilisé, ce qui donne une implémentation plus flexible.
Même «Effective Java» de Joshua Bloch conseille de privilégier la composition plutôt que l'héritage.
Principe de substitution de Barbara Lisk (LSP)
Un autre principe de la boîte à outils SOLID. Il indique que les sous-types doivent être remplaçables pour un sur-type. Autrement dit, les méthodes et fonctions qui fonctionnent avec une superclasse devraient pouvoir fonctionner sans problème avec ses sous-classes.
Le LSP est lié à la fois au principe de responsabilité unique et au principe de répartition des responsabilités. Si une classe fournit plus de fonctionnalités qu'une sous-classe, cette dernière ne prendra pas en charge certaines fonctions, violant ce principe.
Voici un morceau de code qui contredit le LSP.
La méthode area (Rectangle r) calcule l'aire du Rectangle. Le programme plantera après l'exécution de Square, car Square n'est pas un rectangle ici. Selon le principe LSP, les fonctions qui utilisent des références à des classes de base devraient pouvoir utiliser des objets de classes dérivées sans instructions supplémentaires.
Ce principe, qui est une définition spécifique d'un sous-type, a été proposé par Barbara Liskov en 1987 lors d'une conférence dans le rapport principal intitulé «Abstraction et hiérarchie des données» - d'où son nom.
Principe de séparation d'interface (ISP)
Un autre principe SOLIDE. Selon lui, une interface non utilisée ne devrait pas être implémentée. Le respect de ce principe permet au système de rester flexible et adapté à une refactorisation lors de modifications de la logique de travail.
Le plus souvent, cette situation se produit lorsque l'interface contient plusieurs fonctionnalités à la fois et que le client n'a besoin que d'une seule d'entre elles.
Étant donné que l'écriture d'une interface est une tâche difficile, après la fin du travail, la changer sans casser quoi que ce soit sera un problème.
L'avantage du principe ISP en Java est que toutes les méthodes doivent être implémentées en premier, et alors seulement elles peuvent être utilisées par les classes. Par conséquent, le principe permet de réduire le nombre de méthodes.
Programmation pour une interface, pas une implémentation
Tout ici est clair d'après le nom. L'application de ce principe conduit à la création d'un code flexible qui peut fonctionner avec toute nouvelle implémentation d'interface.
Utilisez le type d'interface pour les variables, les types de retour ou le type de l'argument de méthode. Un exemple est l'utilisation de SuperClass, pas de SubClass.
Soit:
Liste des nombres = getNumbers ();Et non:
Numéros ArrayList = getNumbers ();Voici une mise en œuvre pratique de ce qui est dit ci-dessus.
Principe de délégation
Un exemple courant est les méthodes equals () et hashCode () en Java. Lorsqu'il est nécessaire de comparer deux objets, cette action est déléguée à la classe correspondante au lieu du client.
Un avantage du principe est l'absence de duplication de code et un changement de comportement relativement simple. Elle s'applique également à la délégation d'événement.
Tous ces principes permettent d'écrire du code plus flexible, beau et fiable avec une connectivité élevée et une vitesse réduite. Bien sûr, la théorie est bonne, mais pour que le développeur commence vraiment à utiliser les connaissances acquises, il faut de la pratique. La prochaine étape après avoir maîtrisé les principes de la POO peut être l'étude des modèles de conception pour résoudre les problèmes courants de développement logiciel.
Skillbox recommande: