Introduction à la Programmation Orientée Objets

Dans ce tutoriel vous apprendrez à manier la Programmation Orientée Objets, ou POO pour les intimes. Loin d'être aussi complexe qu'elle peut le laisser transparaître, la POO peut se maîtriser rapidiment au point de ne plus pouvoir s'en passer.
A opposer à la programmation dite procédurale, la programmation objet tourne autour d'une unique entité : l'objet, que je vous invite à découvrir de suite...

Avant de rentrer plus avant dans le sujet qui nous intéresse, nous allons commencer par poser un certain nombre de bases.

Il est impossible de parler de Programmation Orientée Objets sans parler d'objet, bien entendu. Tâchons donc de donner une définition aussi complète que possible d'un objet.
Un objet est avant tout une structure de données. Autrement, il s'agit d'une entité chargée de gérer des données et de les stocker sous une certaine forme. En cela, rien ne distingue un objet d'une quelconque autre structure de données. La principale différence vient du fait que l'objet possède la faculté d'offrir une interface entre les données et le programme.

Un objet est de fait constitué de plusieurs éléments :

Si nous résumons, un objet est donc un type servant à stocker des données dans des champs et à les gérer au travers des méthodes.
Si on se rapproche du Pascal, un objet n'est donc qu'une extension évoluée des enregistrements (type record) disposant de procédures et fonctions pour gérer les champs qu'il contient.

Les Programmation Orientée Objets est dirigée par 3 fondamentaux qu'il convient de toujours garder à l'esprit : encapsulation, héritage et polymorphisme. Houlà ! Inutile de fuir en voyant cela, car en fait, il ne cachent que des choses relativement simples. Nous allons tenter de les expliquer tout de suite.

Derrière ce terme se cache le concept même de l'objet : réunir sous la même entité les données et les moyens de les gérer, à savoir les champs et les méthodes.
L'encapsulation introduit donc une nouvele manière de gérer des données. Il ne s'agit plus de déclarer des données générales puis un ensemble de procédures et fonctions destinées à les gérer mais bien de réunir le tout sous le couvert d'une seule et même entité : l'objet.

Sous ce nouveau concept se cache également un autre élément à prendre en compte : pouvoir masquer aux yeux d'un programmeur extérieur tous les rouages d'un objet et donc l'ensemble des procédures et fonctions destinées à la gestion interne de l'objet, auxquelles le programmeur final n'aura pas à avoir accès. L'encapsulation permet donc de masquer un certain nombre de champs et méthodes tout en laissant visible d'autres champs et méthodes. Nous verrons ceci un peu plus loin.

Pour conclure, l'encapsulation permet de garder une cohérence dans la gestion de l'objet, tout en assurant l'intégrité des données qui ne pourront être accédées qu'au travers des méthodes visibles.

Si l'encapsulation pourrait se faire manuellement (grâce à la définition d'une unité par exemple), il en est tout autrement de l'héritage. Cette notion est celle qui s'explique le mieux au travers d'un exemple. Considérons un objet Bâtiment. Cet objet est pour le moins générique, et sa définition reste assez vague. On peut toutefois lui associer divers champs, dont par exemple :

On peut supposer que cet objet Bâtiment dispose d'un ensemble de méthodes destinées à sa gestion. On pourrait ainsi définir entre autres des méthodes pour :

Grâce au concept d'héritage, cet objet Bâtiment va pouvoir donner naissance à un ou des descendants. Ces descendants vont tous bénéficier des caractéristiques propres de leur ancêtre, à savoir ses champs et méthodes. Cependant, les descendants conserve la possibilité de posséder leur propres champs et méthodes. Tout comme un enfant hérite des caractéristiques de ses parents et développe les siennes, un objet peut hériter des caractéristiques de son ancêtre et en posséder de nouvelles.

Ainsi, si l'on poursuit notre exemple, nous allons pouvoir créer un objet Maison. Ce nouvel objet est toujours considéré comme un Bâtiment, il possède donc toujours les champs Adresse ou Loyer et les méthodes destinées par exemple à Payer le loyer.
Toutefois, si notre nouvel objet est un Bâtiment, il n'en reste pas moins qu'il s'agit d'une Maison. On peut donc lui adjoindre d'autres champs et méthodes, et par exemple :

Ce processus d'héritage peut bien sûr être itéré. Autrement dit, il est tout à fait possible de déclarer à présent un descendant de Maison. Mais de la même manière, il n'y a pas de restrictions théoriques concernant le nombre de descendants pour un objet. Ainsi, pourquoi ne pas déclarer des objets Immeuble ou encore Usine dont l'ancêtre commun serait toujours Bâtiment.

Ce concept d'héritage ouvre donc la porte à un nouveau genre de programmation.

Il existe un dernier point à prendre en considération. Certains langages acceptent la Programamtion Orientée Objets à Héritage Multiple. Ceci signifie qu'un objet peut posséder plusieurs ancêtres différents, et hériter des champs et méthodes de chacun. C'est notamment le cas du langage C++. Toutefois, le Pascal standard n'autorise pas l'héritage multiple.
Il ne faut pas nécessairement voir ceci comme une limitation du langage. En effet, l'héritage multiple est souvent à réserver à des cas bien particulier et peut mener à un certain nombre de conflits notamment lorsque deux ancêtres différents possèdent des champs ou méthodes possédant les mêmes noms tout en ayant une signification et un rôle différent.

D'une manière générale, l'héritage multiple est à réserver à des cas bien particuliers. Les dernières version du Pascal, à savoir le Pascal Objet, peuvent néanmoins l'autoriser sous certaines conditions : au niveau des interfaces par exemple. Mais cela reste une exception.