Assez souvent, je rencontre des développeurs qui n'ont pas entendu parler des principes de SOLID (nous . - Trad.) ou la programmation orientée objet (POO), ou entendus, mais ne les utilisent pas dans la 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 aussi bien aux programmeurs débutants qu'aux programmeurs déjà expérimentés.
Nous rappelons: pour tous les lecteurs de "Habr" - une réduction de 10 000 roubles lors de l'inscription à n'importe quel cours Skillbox en utilisant le code promotionnel "Habr".
Skillbox vous recommande : Cours éducatif en ligne .
SEC (Ne vous répétez pas)
Un principe assez simple, dont l'essence ressort clairement du nom : « Ne vous répétez pas ». Pour un programmeur, cela signifie la nécessité d'éviter le code en double, ainsi que la possibilité d'utiliser l'abstraction dans son travail.
S'il y a deux sections répétitives dans le code, elles doivent être combinées en une seule méthode. Si une valeur codée en dur est utilisée plus d’une fois, cela vaut la peine de la convertir en constante publique.
Cela est nécessaire pour simplifier le code et faciliter sa maintenance, ce qui est la tâche principale de la POO. Vous ne devez pas non plus abuser du syndicat, car le même code ne passera pas le contrôle avec OrderId et SSN.
Modifier l'encapsulation
Les produits logiciels de la plupart des entreprises évoluent constamment. Cela signifie que le code doit être modifié, il doit être maintenu. Vous pouvez vous simplifier la vie grâce à l’encapsulation. Cela vous permettra de tester et de maintenir plus efficacement votre base de code existante. .
Si vous écrivez en Java, alors .
Le principe d'ouverture/proximité
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’ils peuvent permettre de modifier leur comportement sans modifier le code source.
Ce principe est important lorsque les modifications apportées au code source nécessitent des révisions, des tests unitaires et d'autres procédures. Le code qui obéit au principe ouvert/fermé ne change pas lorsqu'il est étendu, il pose donc beaucoup moins de problèmes.
Voici un exemple de code qui viole ce principe.
Si vous devez y modifier quelque chose, cela prendra beaucoup de temps, car vous devrez modifier toutes les parties du code qui ont un lien avec le fragment souhaité.
D’ailleurs, l’ouverture-fermeture est l’un des principes de SOLID.
Principe de responsabilité unique (SRP)
Un autre principe de l'ensemble SOLID. Il dit qu '"il n'y a qu'une seule raison qui conduit à un changement de classe". La classe n'a qu'une seule tâche. Il peut exister 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 devraient servir qu’à cela.
L’intérêt de ce principe est qu’il relâche le lien entre un seul logiciel et le code. L'ajout de plusieurs fonctionnalités à une classe introduit une relation entre les deux fonctions. Ainsi, si vous en changez un, vous risquez fort de gâcher le second, lié au premier. Et cela implique d’augmenter les cycles de tests 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 dans lequel AppManager dépend de EventLogWriter, qui à son tour est étroitement lié à AppManager. Si vous avez besoin d'une autre manière d'afficher la notification, qu'il s'agisse d'un push, d'un SMS ou d'un e-mail, vous devez modifier la classe AppManager.
Le problème peut être résolu avec DIP. Ainsi, au lieu d'AppManager, nous demandons un EventLogWriter, qui sera injecté à l'aide du framework.
DIP 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 les autres.
Composition au lieu d'héritage
Les deux principales manières de réutiliser le code sont l’héritage et la composition, chacune ayant ses propres avantages et inconvénients. Le second est généralement préféré car il est plus flexible.
La composition vous donne la possibilité 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" 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 la boîte à outils SOLID. Il indique que les sous-types doivent être remplaçables par un supertype. Autrement dit, les méthodes et fonctions qui fonctionnent avec une superclasse devraient pouvoir fonctionner sans problème avec ses sous-classes.
LSP est lié à la fois au principe de responsabilité unique et au principe de séparation des responsabilités. Si une classe fournit plus de fonctionnalités qu'une sous-classe, alors cette dernière ne prendra pas en charge certaines fonctionnalités, violant ainsi ce principe.
Voici un morceau de code qui contredit LSP.
La méthode Area(Rectangle r) calcule l'aire d'un rectangle. Le programme plantera après l'exécution de Square, puisque Square n'est pas ici un rectangle. Selon le principe LSP, les fonctions qui utilisent des références aux 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 lors d'une conférence de 1987 intitulée "Data Abstraction and Hierarchy" - d'où son nom.
Principe de séparation des interfaces (ISP)
Un autre principe SOLIDE. Selon lui, une interface qui n’est pas utilisée ne devrait pas être implémentée. Suivre ce principe aide le système à rester flexible et refactorisable 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'en a besoin que d'une seule.
L'écriture d'une interface étant une tâche complexe, une fois le travail terminé, la modifier sans rien casser sera un problème.
L'avantage du principe ISP en Java est que toutes les méthodes doivent d'abord être implémentées, et ensuite seulement elles peuvent être utilisées par les classes. Le principe permet donc de réduire le nombre de méthodes.
Programmation pour une interface, pas une implémentation
Ici, tout est clair d'après le nom. L'application de ce principe conduit à un code flexible qui peut fonctionner avec toute nouvelle implémentation d'interface.
Vous devez utiliser un type d'interface pour les variables, les types de retour ou le type d'un argument de méthode. Un exemple consiste à utiliser SuperClass plutôt que SubClass.
I.e:
Liste des numéros = getNumbers();
Et pas:
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 celui des méthodes equals() et hashCode() en Java. Lorsque deux objets doivent être comparés, cette action est déléguée à la classe appropriée au lieu de la classe client.
L’avantage du principe est qu’il n’y a pas de duplication de code et qu’il est relativement simple de changer de comportement. Cela s’applique également à la délégation événementielle.
Tous ces principes vous permettent d'écrire du code plus flexible, plus beau et plus fiable avec une cohésion élevée et un faible couplage. Bien sûr, la théorie est une bonne chose, mais pour qu'un développeur commence réellement à utiliser les connaissances acquises, il a besoin de pratique. La prochaine étape après la maîtrise des principes de la POO peut être l'étude de modèles de conception permettant de résoudre les problèmes courants de développement de logiciels.
Skillbox vous recommande :
- Cours pratique .
- Cours appliqué en ligne .
- Cours pratique de deux ans .
Source: habr.com