Programmation orientée objet
La programmation orientée objet propose de modéliser un programme sous forme de briques logicielles, qui représente un concept ou une entité concrète du monde réel.
Ce style de programmation apporte une différence importante par rapport aux autres paradigmes impératifs car il ne s'agit plus uniquement d'algorithme mais également de modélisation.
Un objet est une structure de données, à la base comme on peut le trouver dans un langage procédural, sauf qu’il contient également des méthodes (appelées messages) permettant d’interagir avec ses données.
Cette structure de données et les méthodes qui lui sont associées est représentée par une classe. Celle ci sert alors de modèle à la création en mémoire des instances d’objets.
Une classe contient une procédure spécifique appelée constructeur, elle est utilisée pour initialiser un objet en fonction des paramètres d’entrée.
Jusqu’ici rien de transcendant, un langage procédural, peut stocker des données structurées et manipuler les données en passant la structure en paramètre des procédures afin qu’elles soient modifiées !
C’est malheureusement là que s’arrête la définition de l’objet pour beaucoup de développeurs non initiés.
Ce n’est donc pas ici que se cache l’intérêt de l’objet, mais dans ce qui suit ...
L’encapsulation
Ce n’est pas ce dont on a envie de parler en premier mais c’est la base et la première différence avec le procédural.
Il s’agit ici de masquer au programmeur final (celui qui utilisera notre objet) le fonctionnement interne de notre objet, à la fois les variables sensibles qu’il n’aura certainement pas le droit de modifier et les procédures internes qui ne doivent absolument pas être appelées n’importe quand.
En échange, l’objet fournit une "façade", partie visible composée de variables et de méthodes qui permettent de refléter l’état de l’objet et de le manipuler.
Avantages :
- Le programmeur final n’a pas à se soucier du fonctionnement interne de l’objet, l’aspect visible de l’objet est souvent plus simple que son fonctionnement interne.
- Le fonctionnement interne peut changer sans que les interactions ne changent
- Le code "interne" reste sécurisé et l'état de l'objet ne peut être modifié par erreur
Exemple :
Pour un nombre complexe, il est possible de le stocker sous différentes formes (cartésienne (réel, imaginaire), trigonométrique, exponentielle (module, angle)).
Cette représentation reste cachée et est interne à l'objet, c'est l'affaire de celui qui développe cet objet.
En revanche, à l'utilisation, l'objet propose des messages permettant d'accéder à toutes ces représentations différentes du même nombre complexe.
En utilisant les seuls messages que comprend notre nombre complexe, les objets appelants sont assurés de ne pas être impactés lors d'un changement de sa structure interne.
Cette dernière n'étant accessible que par les méthodes des messages.
Extrait de wikipedia
L’héritage
Il constitue un aspect important de la réutilisation de code et de la conception en général.
Un objet possède une classe pour modèle. L’héritage consiste à définir de nouvelles classes à partir de classes existantes afin qu’elles servent à leur tour de modèle à des objets plus "précis".
Une classe héritée / dérivée possède tout le comportement de la classe parente et toute sa partie visible, elle peut cependant la compléter et/ou la modifier :
- Ajouter des données et des fonctions
- Remplacer le comportement de la classe parente
- Compléter le comportement pour le rendre plus spécifique
Le principe d’encapsulation est conservé par l’héritage, un mécanisme de portée d’accès permet d’autoriser l’accès à une classe dérivée à certaines données ou méthodes sans qu’elles ne soient utilisables par le programmeur final.
Certains langages autorisent l’héritage multiple, une classe hérite de plusieurs classes, ceci est généralement considéré comme une mauvaise pratique et n’est pas repris dans Java ou C#, mais c’est le cas de C++.
L’héritage permet de modifier le modèle de comportement des objets et leur hiérarchie.
Le polymorphisme
L'idée est que des fonctions de même nom peuvent cohabiter sans confusion au sein d'un programme en fonction du contexte dans lequel elles sont utilisées.
Cette notion s’attache aux méthodes des objets et se décompose en trois sous ensembles (à comprendre mais pas à retenir dans le détail) :
- Polymorphisme Ad’hoc : c’est le cas de classes sans rapport entre elles possèdant une méthode de même nom avec les mêmes paramètres. Il n’y aura pas confusion car le corps de la méthode est lié à la classe qui la décrit, un objet étant lié à une classe, la bonne méthode sera exécutée.
- Polymorphisme Paramétrique : c’est le cas des méthodes de même nom mais de paramètres différents, elles peuvent être décrites au sein d’une même classe. La signature de la fonction et de ses paramètres définira laquelle sera appelée.
- Polymorphisme d’héritage : c’est le cas des méthodes de même nom et de même paramètres redéfinies d’une classe parent à une classe dérivée par le biais de l’héritage. Le corps de la méthode peut alors être complété en faisant un rappel à la méthode de la classe parente ou totalement remplacé.
Rq : Un paramètre de fonction peut être un objet d’une certaine classe. Un objet d’une classe dérivée peut tout aussi bien être transmis à la méthode. Dans ces conditions, il y a une perte partielle d’identité, la méthode n’aura accès qu’à la façade de la classe parente mais le comportement spécifique (définit en polymorphisme d’héritage) sera tout de même conservé de façon transparente.
La programmation orientée objets offre de nombreux autres concepts permettant de modéliser plus efficacement un modèle mais l'idée principale se trouve ici.
Pour plus de détails sur la programmation orientée objet, consulter l'article Programmation orientée objet.
Rubriques connexes :