Programmation Objet

[Kikof]

Pour programmer objet :

- Il faut utiliser un langage qui s'y prête (dit orienté objet) comme le C++, Java, SmallTalk, Delphi...
- Utiliser certaines règles et méthodes de programmation.

Tordons le cou à certaines rumeurs :

- La programmation objet ne permet de faire rien de plus que son homologue non objet (C++ et C par exemple). Il permet juste de faire la même chose mais plus facilement. Un programme peut toutefois arriver à un stade tel de complexité que l'utilisation d'un langage non-objet n'est pratiquement plus possible (mais toujours possible en théorie).
- Il est parfaitement possible de faire des programmes non objets avec des langages orientés objet. Ainsi le C++ est pratiquement compatible avec le C. On peut donc écrire en C avec un compilateur C++. Ce que je fais d'ailleurs en cas de programmes simples, courts et pas destinés à évoluer.


A quoi ça sert ?

L'objet est en fait l'héritier des sous-programmes des vieux langages tels que BASIC, C (fonctions) ou PASCAL (procédures). Il répond à certaines exigences de la programmation moderne telles que :

- Comment puis-je faire exécuter simultanément plusieurs fois le même sous-programme dans le cadre d'un OS multitâches ?
- Comment garantir que le programme pourra évoluer facilement même si des personnes différentes mettent les mains dedans ?
- Comment écrire le moins de code possible pour arriver au résultat désiré ?


Comment ça marche ?

Un objet est un ensemble (cohérent si possible ) de données et de méthodes (fonctions). Lorsque l'on programme, on ne créé pas vraiment un objet mais une fabrique d'objet. C'est une sorte de moule (classe) que l'on pourra utiliser en cours d'exécution pour créer (instancier) autant d'objets de même nature que l'on veut. L'intérêt ici c'est que chaque objet créé à ses propres données indépendantes des autres objets. De la sorte, on peut exécuter plusieurs instances d'objet en même temps sans aucune interférence entre eux.
En pratique, on va décrire la fabrique d'objet (classe) en donnant les différentes variables qu'il va utiliser ainsi que les différentes fonctions qui vont avec.
Un tout petit exemple en C++

// Déclaration de la classe
class Compteur {
   public:
      int iCompteur;       // Variable entière 
      void Initialiser(); // Méthode (fonction) qu'il faut encore écrire
      void Incremente(); // Autre méthode
};

// Implémentation de la classe (écriture des méthodes)
void Compteur::Initialiser() { iCompteur = 0; }
void Compteur::Incremente() { iCompteur = iCompteur + 1; }

// Ailleurs dans le programme
Compteur C1; // C1 est instancié, objet de type compteur
C1.Initialise();
C1.Incremente();
Compteur C2; // Un nouveau compteur différent de C1

L'abstraction de données ?

Rien de sorcier. L'idée de base c'est qu'un utilisateur d'objet (la portion de code qui instancie un objet) ne doit pas se préoccuper comment l'objet fait le travail qu'on lui demande. Plus encore, il ne doit même pas pouvoir accéder aux variables utilisées par l'objet. Ceci évite bien des bugs et permet dans le cadre d'un travail à plusieurs d'éviter qu'un programmeur s'intéresse de trop près au code de son collègue. Il n'a accès qu'a ce que l'on appelle l'interface constituée en général de quelques méthodes. De la sorte, il faut corriger le précédent exemple pour être dans le coup.

// Déclaration de la classe
class Compteur {
   public:
      void Initialiser(); // Méthode (fonction) qu'il faut encore écrire
      void Incremente(); // Autre méthode
   private:
      int iCompteur; // Variable entière 
};

La section private indique que cette variable ne peut être accédée que par les méthodes de la classe et rien d'autre. Ainsi si le code qui instancie un objet Compteur essaie d'accéder à iCompteur, le compilateur générera une erreur.

Compteur C1;
C1.iCompteur = 10; // Erreur de compilation

L'héritage ?

Il s'agit d'un mécanisme qui permet d'écrire le moins de code possible pour arriver à un résultat donné. Un bon exemple est l'écriture d'un jeu, disons un pacman. Si on l'écrit sans utiliser d'objets, on va s'apercevoir que l'on a du code en double. En effet les fantômes et les gloutons ont au moins un point commun : ils se déplacent sur la même surface. Par exemple les tests pour savoir si le glouton et le fantôme arrivent au bord du jeu, ou sur un mur vont être les mêmes.
En programmant objet on évite la redondance en faisant hériter les classes Glouton et Fantome d'une même classe de base, disons Element_Mobile. Celle-ci contiendra une bonne fois pour toute le code concernant le déplacement sur la surface de jeu.
Lorsqu'une classe hérite d'une autre, elle prend toutes les variables et les méthodes de celle-ci mais en ajoute d'autres. Exemple, toujours en C++ :

class Element_Mobile {
   public:
      void Avance(Direction);
      (...)
   protected: // Comme private mais les classes dérivées peuvent y accéder
      int X,Y; // Coordonnées de l'élément mobile
      (...)
};

class Glouton : public Element_Mobile { 
   public:
      void Mange_Pastille();
      (...)
   private:
      Pastille pastille_mangee;
      (...)
};

class Fantome : public Element_Mobile {
   public:
      void Mange_Glouton();
      (...)
};

Par exemple si on écrit :

Fantome F1;
F1.Avance(Nord);        // Correct
F1.Mange_Glouton();    // Correct
F1.Mange_Pastille();  // Erreur, méthode appartenant à Glouton
F1.X = 2;            // Erreur donnée protégée, non accessible

Points non abordés mais importants :

Constructeurs et destructeurs d'objets : Il s'agit de méthodes particulières appartenant à la classe considérée et qui sont exécutées respectivement à l'instanciation d'un objet et à sa destruction.
Polymorphisme : faculté que peut avoir une méthode d'une classe dérivée d'être exécutée plutôt que la méthode de même nom dans la classe de base (dans certaines circonstances particulières). Un peu trop long à expliquer mais d'une grande importance en pratique.


C'est facile la programmation objet ?

La facilité est une notion subjective qui dépend essentiellement de l'individu qui l'évoque.
De mon point de vue, ayant commencé par des langages non orientés objet, je répondrais non.
Apprendre à utiliser un langage, orienté objet ou pas, n'est pas difficile. Par contre, arriver à bien structurer objet un programme, ce n'est pas évident.
Cela requiert, je pense, une habitude des problèmes structurels récurrents que l'on rencontre en programmant.
Programmer objet demande bien plus de réflexion que la programmation procédurale. Bien plus d'énergie et d'astuces doivent être déployées dans la structure du programme que dans les algorithmes.

Cela étant, même en programmant mal, on arrive à faire des choses assez sympa. Je crois donc qu'il n'y a donc aucune raison de rester sur un langage non orienté objet.