programmes pour validation de cours

Rédaction de programmes : orienté objet ou structuré ?

En rédigeant des programmes pour validation de cours, nous devons souvent conseiller au client si le programme doit être écrit en orienté objet ou en structuré. Bien entendu, le plus important dans ce cas est la manière dont vous avez appris à programmer pendant les cours pour lesquels le programme commandé doit être réalisé...
C'est donc vous qui devriez nous dire comment doit être écrit le programme pour validation de cours que nous devons réaliser pour vous. Comme c'est très important, nous vous conseillons de vous en assurer, car une mauvaise décision sur ce point peut se traduire par une note insuffisante à la validation.
Toutefois, si l'enseignant laisse les étudiants libres sur cette question, alors, à vrai dire, la réponse peut se résumer en un seul mot : objet. Mais commençons par le début, c'est-à-dire par les définitions :
La programmation structurée est un développement du concept de programmation procédurale ; il s'agit donc d'une méthodologie de rédaction de programmes dont la base est la division hiérarchique du code en modules communiquant entre eux par des interfaces strictement définies. Les données, les procédures et les fonctions ne sont pas directement liées entre elles, et les instructions sont exécutées séquentiellement. La base de la programmation structurée est constituée des instructions conditionnelles et des boucles, alors que toutes sortes de sauts sont considérés comme une forme d'impolitesse : reliquat de la programmation linéaire, ils sont (à juste titre) tenus pour quelque chose qui nuit à la lisibilité du code source et complique son analyse.
En revanche, la programmation orientée objet est une méthodologie de rédaction de programmes informatiques qui définit les programmes à l'aide d'objets réunissant les données et les comportements du programme (définis sous forme de procédures et de fonctions, appelées en programmation orientée objet « méthodes »). Le programme s'exprime comme la somme de tels objets, qui communiquent entre eux afin d'accomplir les tâches fixées au programme. Cela permet de réaliser efficacement de grands projets par des équipes de programmeurs, en les assemblant à partir d'objets qui collaborent et sont chacun responsables d'un élément précis du logiciel.
Voilà pour les définitions objectives ; passons maintenant aux opinions (sans doute tout à fait subjectives) : à mon avis, bien que la programmation orientée objet impose au programmeur un certain régime et des contraintes qui découragent souvent les jeunes adeptes de la programmation de s'y mettre, consacrer un peu de temps à se familiariser avec les principes de la programmation orientée objet apporte des avantages indéniables.

Lesquels ? On pourrait en énumérer beaucoup, mais je ne citerai que ceux qui me semblent les plus importants : premièrement, tout programme bien écrit en orienté objet peut être réutilisé dans un travail ultérieur, en transférant les classes qu'il définit vers une autre application. Deuxièmement, il est plus facile de localiser une erreur, et il est également plus facile de comprendre un programme qu'on a soi-même écrit il y a quelque temps. Troisièmement, il est beaucoup plus simple de modifier le code du programme : contrairement à la programmation structurée, où, pour corriger ou changer le moindre petit fragment du logiciel, il faudrait souvent éditer de nombreux passages du code source, en consacrant au préalable énormément de temps à comprendre ce que l'on avait voulu dire en écrivant les choses de telle manière et pas autrement. (Croyez-moi, même les programmes écrits soi-même paraissent tout à fait étrangers, et souvent incompréhensibles, après quelques mois, et a fortiori après des années.)
Les possibilités qui découlent de l'approche orientée objet des données et de la rédaction de programmes orientée objet pour des équipes entières de programmeurs semblent particulièrement importantes : des gens qui, dans le monde réel, ne se connaissent souvent même pas, mais qui créent ensemble de vastes applications en communiquant uniquement par les descriptions des interfaces des méthodes d'une classe donnée, sans avoir besoin de savoir ce qui se passe à l'intérieur. Un autre avantage de la programmation orientée objet est que le code est lisible et clair : il suffit de jeter un coup d'œil au fichier de définition pour savoir au bout d'un instant à quoi sert telle classe ou telle méthode,
La situation est tout autre avec la programmation structurée : tout d'abord, il est extrêmement difficile d'obtenir un code lisible pour les applications de grande taille ; ensuite, un code écrit une fois ne se prête pas à une réutilisation, car l'adapter à d'autres usages nécessite le plus souvent de très nombreuses corrections à différents endroits. Pour cette raison, un programme écrit de façon structurée servira rarement une seconde fois : il faut en général moins de temps au programmeur pour écrire une nouvelle classe de zéro que pour se débattre sans fin dans un ancien code.
Malgré ces évidences, dans nos universités, on enseigne beaucoup plus souvent la programmation structurée, et c'est aussi ce type de programmes pour validation de cours que l'on attend des étudiants. Cela ne concerne bien sûr pas les filières informatiques, où la programmation orientée objet est déjà la norme, mais dans les filières qui n'ont pas de lien direct avec l'informatique, elle reste encore une rareté.
Pour conclure cet article, j'aimerais exprimer l'espoir que ces quelques mots que j'ai écrits vous convaincront d'apprendre la programmation orientée objet. Je ne me fais pas d'illusions : je n'ai pas épuisé le sujet, j'ai seulement abordé une partie des questions et décrit une petite fraction des avantages de la programmation orientée objet. Il y en a bien d'autres, dont vous vous rendrez compte en travaillant sur des tâches concrètes (surtout si vous devez travailler en groupes).

Autres documents sur la rédaction de programmes informatiques