Il arrive assez souvent que je rencontre des développeurs qui n'ont pas entendu parler des principes SOLID (nous . — NDLR) ou de la programmation orientée objet (POO), ou qui en ont entendu parler mais ne les utilisent pas en pratique. Cet article décrit les avantages des principes de la POO qui aident le développeur dans son travail quotidien. Certains d'entre eux sont bien connus, d'autres moins, donc l'article sera utile tant aux débutants qu'aux programmeurs expérimentés.
Rappelons-le : Pour tous les lecteurs de « Habr » — une remise de 10 000 roubles lors de l'inscription à n'importe quel cours Skillbox avec le code promo « Habr ».
Skillbox recommande : Cours en ligne éducatif .
DRY (Don't Repeat Yourself)
Un principe assez simple, dont la signification est claire à partir du titre : « Ne te répète pas ». Pour un développeur, cela signifie qu'il est nécessaire d'éviter le code dupliqué et de pouvoir utiliser l'abstraction dans son travail.
Si le code contient deux sections répétées, elles doivent être combinées en une seule méthode. Si une valeur codée en dur est utilisée plus d'une fois, elle doit être convertie en une constante publique.
Cela est nécessaire pour simplifier le code et rendre son support plus facile, ce qui est l'objectif principal de la POO. Il ne faut pas non plus abuser des regroupements, car le même code ne passera pas le test tant pour OrderId que pour SSN.
Encapsulation des changements
Les produits logiciels de la plupart des entreprises évoluent constamment. Cela signifie qu'il faut apporter des modifications au code, le maintenir. On peut se faciliter la vie grâce à l'encapsulation. Cela permettra de tester et de maintenir plus efficacement la base de code existante. .
Si vous codez en Java, alors .
Principe de l'ouverture/fermeture
Ce principe peut être facilement mémorisé en lisant la déclaration suivante : « Les entités logicielles (classes, modules, fonctions, etc.) doivent être ouvertes à l'extension, mais fermées à la modification ». En pratique, cela signifie qu'elles peuvent permettre de changer leur comportement sans modifier le code source.
Ce 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 respecte le principe d'ouverture/fermeture ne change pas lors de l'extension, donc il pose beaucoup moins de problèmes.
Voici un exemple de code qui enfreint ce principe.
Si des modifications sont nécessaires, cela prendra beaucoup de temps, car il faudra changer tous les segments de code ayant un lien avec le fragment concerné.
Au fait, la transparence et l'opacité sont l'un des principes SOLID.
Principe de responsabilité unique (SRP)
Un autre principe du jeu de règles SOLID. Il stipule qu'il n'y a qu'une seule raison de modifier une classe. Une classe ne traite qu'un seul problème. Elle peut avoir plusieurs méthodes, mais chacune d'elles ne sert qu'à résoudre le problème global. Toutes les méthodes et propriétés doivent uniquement servir cela.
La valeur de ce principe réside dans le fait qu'il réduit la dépendance entre différents composants du logiciel et le code. Si l'on ajoute plus d'une fonctionnalité à une classe, cela introduit un lien entre deux fonctions. Ainsi, si l'une d'elles est modifiée, il y a un grand risque de détruire l'autre, liée à la première. Cela signifie une augmentation des cycles de test pour identifier tous les problèmes à l'avance.
Principe d'inversion des dépendances (DIP)
L'exemple de code ci-dessus montre que AppManager dépend de EventLogWriter, qui est lui-même étroitement lié à AppManager. Si un autre moyen de montrer des notifications est nécessaire, que ce soit par push, SMS ou email, il faut modifier la classe AppManager.
Le problème peut être résolu grâce au DIP. Ainsi, au lieu de AppManager, nous demandons EventLogWriter, qui sera réalisé à l'aide du framework.
Le DIP permet de remplacer facilement des modules individuels par d'autres, en modifiant le module de dépendance. Cela permet de changer un module sans affecter les autres.
Composition plutôt qu'héritage
Il existe deux principales façons de réutiliser du code — l'héritage et la composition, chacune ayant ses propres avantages et inconvénients. En général, la composition est préférée car elle est plus flexible.
La composition permet de modifier le comportement d'une classe à l'exécution en configurant ses propriétés. Le polymorphisme est utilisé lors de l'implémentation des interfaces, ce qui offre une réalisation 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 Liskov (LSP)
Un autre principe de l'outil SOLID. Il stipule que les sous-types doivent être substituables pour le supertype. Autrement dit, les méthodes et fonctions qui fonctionnent avec la superclasse doivent pouvoir fonctionner sans problème avec ses sous-classes.
Le LSP est lié à la fois au principe de responsabilité unique et au principe de séparation des responsabilités. Si une classe offre plus de fonctionnalités qu'une sous-classe, cette dernière ne prendra pas en charge certaines fonctions, compromettant ce principe.
Voici un extrait de code qui contrevient au LSP.
La méthode area(Rectangle r) calcule l'aire du Rectangle. Le programme échouera 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 doivent pouvoir utiliser des objets de classes dérivées sans instructions supplémentaires.
Ce principe, qui est une définition spécifique du sous-type, a été proposé par Barbara Liskov en 1987 lors d'une conférence dans un discours principal intitulé « Abstraction des données et hiérarchie » – d'où son nom.
Principe de séparation des interfaces (ISP)
Un autre principe SOLID. Selon lui, une interface qui n'est pas utilisée ne doit pas être implémentée. Respecter ce principe aide le système à rester flexible et adapté au refactoring lors de modifications de la logique de fonctionnement.
Cette situation se produit le plus souvent lorsque l'interface contient plusieurs fonctionnalités et que le client n'en a besoin que d'une seule.
Étant donné que la rédaction d'une interface est une tâche complexe, il sera problématique de la modifier après son achèvement sans rien compromettre.
L'avantage du principe ISP en Java est qu'il faut d'abord implémenter toutes les méthodes, et seulement ensuite elles peuvent être utilisées par des classes. Ainsi, le principe permet de réduire le nombre de méthodes.
Programmer pour l'interface, et non pour l'implémentation
Tout est clair dans le nom. L'application de ce principe conduit à la création d'un code flexible qui pourra fonctionner avec toute nouvelle implémentation de l'interface.
Il convient d'utiliser le type d'interface pour les variables, les types de retour ou le type des arguments de méthode. Exemple : utilisation de SuperClass plutôt que SubClass.
C'est-à-dire :
List numbers = getNumbers();
Pas :
ArrayList numbers = getNumbers();
Voici une mise en œuvre pratique de ce qui a été 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 appropriée plutôt qu'au client.
L'avantage de ce principe est l'absence de duplication de code et un changement de comportement relativement simple. Il est également applicable à la délégation des événements.
Tous ces principes permettent d'écrire un code plus flexible, élégant et fiable, avec une forte cohésion et un faible couplage. Bien sûr, la théorie est importante, mais pour qu'un développeur commence réellement à utiliser ces connaissances, il faut de la pratique. L'étape suivante après la maîtrise des principes de la POO peut être l'étude des modèles de conception pour résoudre des problèmes communs de développement de logiciels.
Skillbox recommande :
- Cours pratique .
- Cours en ligne appliqué .
- Cours pratique de deux ans .
Source : habr.com
