La programmation orientée objet (POO) n’est pas un concept nouveau. Théorisée dans les années 80, elle a vu sa formalisation et son essor dans les années 90. On la retrouve maintenant dans la plupart des langages de programmation d’assez haut niveau.
J’ai pu acquérir et développer une mentalité et des compétences (mindset et skillset) de développeur qui pense objet, en me frottant à différents langages (surtout C++ et python, mais aussi du C# et du JavaScript), dans le cadre de projets très variés d’informatique industrielle pour des systèmes de lecture automatique de plaque minéralogique, de traitement du signal, de système de mesure ferroviaire, de robotique, d’intelligence artificielle, d’application web et de jumeau numérique.
Tout cela me sert au quotidien dans mes missions de CTO pour Altametris.
Car oui, dans nos métiers très technologiques, les objets sont partout et penser objet permet de mieux comprendre et d’appréhender les sujets à traiter (en plus de savoir de quoi je parle quand je vous parle d’azure et de cloud ⬇️).
Mais qu’est ce qu’un objet en premier lieu?
Concrètement, un objet est une structure de données qui répond à un ensemble de messages. Cette structure de données définit son état tandis que l’ensemble des messages qu’il comprend décrit son comportement :
- les données, ou champs, qui décrivent sa structure interne sont appelées ses attributs ;
- l’ensemble des messages forme ce que l’on appelle l’interface de l’objet ; c’est seulement au travers de celle-ci que les objets interagissent entre eux. La réponse à la réception d’un message par un objet est appelée une méthode ; elle décrit quelle réponse doit être donnée au message.
Certains attributs et/ou méthodes (ou plus exactement leur représentation informatique) sont cachés : c’est le principe d’encapsulation. Ainsi, l’application peut modifier la structure interne des objets ou leurs méthodes associées sans avoir d’impact sur les utilisateurs de l’objet.
L’autre concept clés dans la POO objet est l’abstraction. Son objectif principal est de gérer la complexité en masquant les détails inutiles à l’utilisateur. Cela permet à l’utilisateur d’implémenter une logique plus complexe sans comprendre ni même penser à toute la complexité cachée.
L’abstraction est bien sûr un concept général que vous pouvez trouver dans le monde réel ainsi que dans la POO. Tous les objets du monde réel, comme votre voiture, ou votre maison, en masquant les détails internes fournissent une abstraction.
Abstraction et encapsulation facilitent beaucoup la gestion de la complexité en la divisant en petites parties. Dans le meilleur des cas, il est possible de les utiliser sans comprendre comment elles fournissent les fonctionnalités. Et cela permet de diviser la complexité d’un applicatif en parties contrôlables, maintenables et interprétables en toute agilité (souvenez vous le monolithe).
Les deux autres concepts fondamentaux de la POO sont le polymorphisme et l’héritage. Ce sont deux notions assez liées car elles permettent de fournir des interfaces uniques pour différents types de données tout en rendant le code réutilisable. Il faut savoir qu’ils existent, mais ce sont surtout des concepts techniques.
Principes des POO
Pour bien faire de la POO, on retrouve des grands principes comme :
- SOLID. Abréviation de l’anglicisme Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion. Cinq principes qui, lorsqu’ils sont appliqués ensembles, rendront plus portables un programme et plus facile à entretenir à long terme .
- DRY pour don’t repeat yourself. Éviter la redondance de code au sein d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions. Lorsque le principe DRY est bien appliqué, la modification d’un élément d’un système ne change pas les autres éléments non liés logiquement. De plus, tous les éléments liés logiquement changent uniformément, de manière prévisible et restent synchronisés .
- KISS pour Keep it simple, stupid. Pas pour dire qu’il ne faille pas réaliser des systèmes complexes, mais que pour y arriver, il faut toujours privilégier la simplicité dans la conception et que toute complexité non indispensable devrait être évitée dans toute la mesure du possible .
Ces principes s’appliquent à bien des domaines différents.
Ce que l’on notera aussi, et cela pourra être développé dans un prochain billet autour du devops, c’est que ces notions sont primordiales lorsque l’on applique des méthodes de gestion de projet de développement agile, comme à travers l’usage du framework scrum.
Au final, quand on doit concevoir, modéliser et surtout réaliser un système de gestion et de valorisation du patrimoine digital, architecturé en microservices, qui sont autant d’objets avec des états (stockage des données) et des interfaces (des API), la meilleure philosophie à adopter est celle de la POO et ses principes fondamentaux, pour peu que vous les maîtrisiez.
Sources
- What is Object-Oriented Programming (OOP)? (techtarget.com)
- Principe SOLID | Essential Developer Skills (essential-dev-skills.com)
- Le principe KISS appliqué à la conception du langage de programmation? (qastack.fr)
- Comment organiser votre code orienté objet avec l’héritage (savoirdanslavie.com)
- To address microservices issues, turn to OOP principles (techtarget.com)
/filters:no_upscale()/articles/microservices-design-ideals/en/resources/1figure-1-different-BFF-for-each-client-1598955550326.jpg)