{"id":34855,"date":"2019-10-31T22:00:51","date_gmt":"2019-10-31T19:00:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik\/"},"modified":"2019-10-31T22:00:51","modified_gmt":"2019-10-31T19:00:51","slug":"10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 principes de la programmation orient\u00e9e objet que chaque d\u00e9veloppeur doit conna\u00eetre","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nIl arrive assez souvent que je rencontre des d\u00e9veloppeurs qui n'ont pas entendu parler des principes SOLID (nous en avons parl\u00e9 en d\u00e9tail ici<\/a><\/noindex>. \u2014 NDLR) ou de la programmation orient\u00e9e objet (POO), ou qui en ont entendu parler mais ne les utilisent pas en pratique. Cet article d\u00e9crit les avantages des principes de la POO qui aident le d\u00e9veloppeur dans son travail quotidien. Certains d'entre eux sont bien connus, d'autres moins, donc l'article sera utile tant aux d\u00e9butants qu'aux programmeurs exp\u00e9riment\u00e9s.
\n<\/a><\/noindex><\/p>\n

Rappelons-le :<\/b> Pour tous les lecteurs de \u00ab Habr \u00bb \u2014 une remise de 10 000 roubles lors de l'inscription \u00e0 n'importe quel cours Skillbox avec le code promo \u00ab Habr \u00bb.<\/i><\/p>\n

Skillbox recommande :<\/b> Cours en ligne \u00e9ducatif \u00ab D\u00e9veloppeur Java \u00bb<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (Don't Repeat Yourself)<\/h3>\n

\nUn principe assez simple, dont la signification est claire \u00e0 partir du titre : \u00ab Ne te r\u00e9p\u00e8te pas \u00bb. Pour un d\u00e9veloppeur, cela signifie qu'il est n\u00e9cessaire d'\u00e9viter le code dupliqu\u00e9 et de pouvoir utiliser l'abstraction dans son travail.<\/p>\n

Si le code contient deux sections r\u00e9p\u00e9t\u00e9es, elles doivent \u00eatre combin\u00e9es en une seule m\u00e9thode. Si une valeur cod\u00e9e en dur est utilis\u00e9e plus d'une fois, elle doit \u00eatre convertie en une constante publique.<\/p>\n

Cela est n\u00e9cessaire 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\u00eame code ne passera pas le test tant pour OrderId que pour SSN.<\/p>\n

Encapsulation des changements<\/h3>\n

\nLes produits logiciels de la plupart des entreprises \u00e9voluent constamment. Cela signifie qu'il faut apporter des modifications au code, le maintenir. On peut se faciliter la vie gr\u00e2ce \u00e0 l'encapsulation. Cela permettra de tester et de maintenir plus efficacement la base de code existante. Voici un exemple<\/a><\/noindex>.<\/p>\n

Si vous codez en Java, alors par d\u00e9faut, attribuez un acc\u00e8s private aux m\u00e9thodes et variables<\/a><\/noindex>.<\/p>\n

Principe de l'ouverture\/fermeture<\/h3>\n

\nCe principe peut \u00eatre facilement m\u00e9moris\u00e9 en lisant la d\u00e9claration suivante : \u00ab Les entit\u00e9s logicielles (classes, modules, fonctions, etc.) doivent \u00eatre ouvertes \u00e0 l'extension, mais ferm\u00e9es \u00e0 la modification \u00bb. En pratique, cela signifie qu'elles peuvent permettre de changer leur comportement sans modifier le code source.<\/p>\n

Ce principe est important lorsque les modifications du code source n\u00e9cessitent une r\u00e9vision, des tests unitaires et d'autres proc\u00e9dures. Le code qui respecte le principe d'ouverture\/fermeture ne change pas lors de l'extension, donc il pose beaucoup moins de probl\u00e8mes.<\/p>\n

Voici un exemple de code qui enfreint ce principe.<\/p>\n

\"10
\n
\nSi des modifications sont n\u00e9cessaires, cela prendra beaucoup de temps, car il faudra changer tous les segments de code ayant un lien avec le fragment concern\u00e9.<\/p>\n

Au fait, la transparence et l'opacit\u00e9 sont l'un des principes SOLID.<\/p>\n

Principe de responsabilit\u00e9 unique (SRP)<\/h3>\n

\nUn autre principe du jeu de r\u00e8gles SOLID. Il stipule qu'il n'y a qu'une seule raison de modifier une classe. Une classe ne traite qu'un seul probl\u00e8me. Elle peut avoir plusieurs m\u00e9thodes, mais chacune d'elles ne sert qu'\u00e0 r\u00e9soudre le probl\u00e8me global. Toutes les m\u00e9thodes et propri\u00e9t\u00e9s doivent uniquement servir cela. <\/p>\n

\"10
\n
\nLa valeur de ce principe r\u00e9side dans le fait qu'il r\u00e9duit la d\u00e9pendance entre diff\u00e9rents composants du logiciel et le code. Si l'on ajoute plus d'une fonctionnalit\u00e9 \u00e0 une classe, cela introduit un lien entre deux fonctions. Ainsi, si l'une d'elles est modifi\u00e9e, il y a un grand risque de d\u00e9truire l'autre, li\u00e9e \u00e0 la premi\u00e8re. Cela signifie une augmentation des cycles de test pour identifier tous les probl\u00e8mes \u00e0 l'avance.<\/p>\n

Principe d'inversion des d\u00e9pendances (DIP)<\/h3>\n

\n\"10
\n
\nL'exemple de code ci-dessus montre que AppManager d\u00e9pend de EventLogWriter, qui est lui-m\u00eame \u00e9troitement li\u00e9 \u00e0 AppManager. Si un autre moyen de montrer des notifications est n\u00e9cessaire, que ce soit par push, SMS ou email, il faut modifier la classe AppManager.<\/p>\n

Le probl\u00e8me peut \u00eatre r\u00e9solu gr\u00e2ce au DIP. Ainsi, au lieu de AppManager, nous demandons EventLogWriter, qui sera r\u00e9alis\u00e9 \u00e0 l'aide du framework.<\/p>\n

Le DIP permet de remplacer facilement des modules individuels par d'autres, en modifiant le module de d\u00e9pendance. Cela permet de changer un module sans affecter les autres.<\/p>\n

Composition plut\u00f4t qu'h\u00e9ritage<\/h3>\n

\n\"10Il existe deux principales fa\u00e7ons de r\u00e9utiliser du code \u2014 l'h\u00e9ritage et la composition, chacune ayant ses propres avantages et inconv\u00e9nients. En g\u00e9n\u00e9ral, la composition est pr\u00e9f\u00e9r\u00e9e car elle est plus flexible.<\/p>\n

La composition permet de modifier le comportement d'une classe \u00e0 l'ex\u00e9cution en configurant ses propri\u00e9t\u00e9s. Le polymorphisme est utilis\u00e9 lors de l'impl\u00e9mentation des interfaces, ce qui offre une r\u00e9alisation plus flexible.<\/p>\n

M\u00eame \"Effective Java\" de Joshua Bloch conseille de privil\u00e9gier la composition plut\u00f4t que l'h\u00e9ritage.<\/p>\n

Principe de substitution de Barbara Liskov (LSP)<\/h3>\n

\nUn autre principe de l'outil SOLID. Il stipule que les sous-types doivent \u00eatre substituables pour le supertype. Autrement dit, les m\u00e9thodes et fonctions qui fonctionnent avec la superclasse doivent pouvoir fonctionner sans probl\u00e8me avec ses sous-classes.<\/p>\n

Le LSP est li\u00e9 \u00e0 la fois au principe de responsabilit\u00e9 unique et au principe de s\u00e9paration des responsabilit\u00e9s. Si une classe offre plus de fonctionnalit\u00e9s qu'une sous-classe, cette derni\u00e8re ne prendra pas en charge certaines fonctions, compromettant ce principe.<\/p>\n

Voici un extrait de code qui contrevient au LSP.<\/p>\n

\"10
\n
\nLa m\u00e9thode area(Rectangle r) calcule l'aire du Rectangle. Le programme \u00e9chouera apr\u00e8s l'ex\u00e9cution de Square, car Square n'est pas un Rectangle ici. Selon le principe LSP, les fonctions qui utilisent des r\u00e9f\u00e9rences \u00e0 des classes de base doivent pouvoir utiliser des objets de classes d\u00e9riv\u00e9es sans instructions suppl\u00e9mentaires.<\/p>\n

Ce principe, qui est une d\u00e9finition sp\u00e9cifique du sous-type, a \u00e9t\u00e9 propos\u00e9 par Barbara Liskov en 1987 lors d'une conf\u00e9rence dans un discours principal intitul\u00e9 \u00ab Abstraction des donn\u00e9es et hi\u00e9rarchie \u00bb \u2013 d'o\u00f9 son nom.<\/p>\n

Principe de s\u00e9paration des interfaces (ISP)<\/h3>\n

\nUn autre principe SOLID. Selon lui, une interface qui n'est pas utilis\u00e9e ne doit pas \u00eatre impl\u00e9ment\u00e9e. Respecter ce principe aide le syst\u00e8me \u00e0 rester flexible et adapt\u00e9 au refactoring lors de modifications de la logique de fonctionnement.<\/p>\n

Cette situation se produit le plus souvent lorsque l'interface contient plusieurs fonctionnalit\u00e9s et que le client n'en a besoin que d'une seule.<\/p>\n

\u00c9tant donn\u00e9 que la r\u00e9daction d'une interface est une t\u00e2che complexe, il sera probl\u00e9matique de la modifier apr\u00e8s son ach\u00e8vement sans rien compromettre.<\/p>\n

L'avantage du principe ISP en Java est qu'il faut d'abord impl\u00e9menter toutes les m\u00e9thodes, et seulement ensuite elles peuvent \u00eatre utilis\u00e9es par des classes. Ainsi, le principe permet de r\u00e9duire le nombre de m\u00e9thodes.<\/p>\n

\"10
\n <\/p>\n

Programmer pour l'interface, et non pour l'impl\u00e9mentation<\/h3>\n

\nTout est clair dans le nom. L'application de ce principe conduit \u00e0 la cr\u00e9ation d'un code flexible qui pourra fonctionner avec toute nouvelle impl\u00e9mentation de l'interface.<\/p>\n

Il convient d'utiliser le type d'interface pour les variables, les types de retour ou le type des arguments de m\u00e9thode. Exemple : utilisation de SuperClass plut\u00f4t que SubClass.<\/p>\n

C'est-\u00e0-dire :<\/p>\n

List numbers = getNumbers();<\/i><\/p>\n

Pas :<\/p>\n

ArrayList numbers = getNumbers();<\/i><\/p>\n

Voici une mise en \u0153uvre pratique de ce qui a \u00e9t\u00e9 dit ci-dessus.<\/p>\n

\"10
\n <\/p>\n

Principe de d\u00e9l\u00e9gation<\/h3>\n

\nUn exemple courant est les m\u00e9thodes equals() et hashCode() en Java. Lorsqu'il est n\u00e9cessaire de comparer deux objets, cette action est d\u00e9l\u00e9gu\u00e9e \u00e0 la classe appropri\u00e9e plut\u00f4t qu'au client.<\/p>\n

L'avantage de ce principe est l'absence de duplication de code et un changement de comportement relativement simple. Il est \u00e9galement applicable \u00e0 la d\u00e9l\u00e9gation des \u00e9v\u00e9nements.<\/p>\n

\"10
\n
\nTous ces principes permettent d'\u00e9crire un code plus flexible, \u00e9l\u00e9gant et fiable, avec une forte coh\u00e9sion et un faible couplage. Bien s\u00fbr, la th\u00e9orie est importante, mais pour qu'un d\u00e9veloppeur commence r\u00e9ellement \u00e0 utiliser ces connaissances, il faut de la pratique. L'\u00e9tape suivante apr\u00e8s la ma\u00eetrise des principes de la POO peut \u00eatre l'\u00e9tude des mod\u00e8les de conception pour r\u00e9soudre des probl\u00e8mes communs de d\u00e9veloppement de logiciels.<\/p>\n

Skillbox recommande :<\/b><\/p>\n