Définitions de programmation impérative et orientée objet
Bonsoir à tous les forumeurs :D,
Une amie qui commence ses études me demande une définition de la programmation impérative et de la programmation orientée objet, à défaut d'en avoir trouvée elle-même.
Je sais ce que ce sont, mais j'ai beaucoup de mal, comme elle, à trouver (en anglais comme en français, sur le Net comme dans des livres) une vraie définition.
Je me suis rabattu sur le fait d'écrire moi-même les définitions, mais je ne suis pas certain de leur exactitude. C'est pouquoi je vous demande si vous n'auriez pas de vraies définitions de ces termes, ou bien des remarques sur mes tentatives :
Citation:
Programmation impérative
Paradigme de programmation avec lequel un programme est constitué de procédures et fonctions (plus généralement routines) sans liens particuliers agissant sur des données dissociées de ces routines.
Chaque routine est une succession d’instructions que le processeur d’un ordinateur peut exécuter. Les données n’ont pas de lien direct avec les routines. C’est pourquoi une modification de la structure de ces données peut entraîner de sérieux problèmes de maintenance.
Programmation orientée objet (POO)
Paradigme de programmation avec lequel un programme est constitué d’objets, entités de données munies de données et de routines (dans ce cas appelées méthodes) liées entre elles. C’est une évolution de la programmation impérative.
Les champs (données) et méthodes d’un objet étant intimement liés, les problèmes de maintenance ne se posent plus.
:merci: d'avance.
PS : si vous me donnez une définition d'un site Web, d'un livre, ou autre, merci de me donner les sources :)
Programmation impérative.
Je crois qu'on doit avant tout distinguer deux sortes de données:
:arrow: Les données abstraites, qui sont de nature purement mathématique: nombres, chaînes de caractères (non mutables), booléens, aggrégats de données abstraites (non mutables), fonctions, liste de données abstraites etc...
:arrow: Les données concrètes qui sont en lien avec le temps et l'espace, comme les connexions réseau, les fenêtres graphiques, les fichiers, les variables (c'est à dire les données dont le contenu ou une partie du contenu peut être changé dynamiquement; on dit aussi qu'elles sont mutables), etc...
Il y a des critères simples et infaillibles pour les distinguer les unes des autres. Demandez vous par exemple, si de telles données doivent être créées ou ouvertes. Si c'est le cas ce sont des donnés concrètes: on ouvre des fichiers, des connexions et des fenêtres, on crée dynamiquement des variables, mais on n'ouvre pas des nombres, des matrices ou des chaînes de caractères.
Note: l'allocation de mémoire pour un aggrégat par exemple ou une chaîne de caractères ne devrait pas être considéré comme une ouverture. Toutefois, si l'aggrégat est mutable et si le langage ne gère pas la mémoire automatiquement, on est obligé de le considérer comme une donnée concrète, car c'est alors une variable (à plusieurs places).
Demandez-vous également si le principe d'identité (de la POO) s'applique. Ce principe dit que deux objets (des sortes de données) peuvent très bien être distincts, alors que tous leurs attributs sont identiques. S'il s'applique, il s'agit de données concrètes. Par exemple, vous ouvrez deux connexions réseau avec la même adresse IP et le même numéro de port, et vous avez deux connexions distinctes. Par contre, si vous avez deux nombres qui ont la même valeur, ils sont égaux (même s'ils sont écrits à des endroits différents de la mémoire).
Maintenant, une programmation est strictement non impérative (on dit aussi déterministe) si elle ne manipule que des données abstraites. Elle ne crée et n'ouvre donc rien. Bien entendu, la mémoire devant être gérée dans tous les cas de figure, une telle programmation n'est réellement possible qu'avec un langage qui gère automatiquement la mémoire (garbage-collector). C'est le cas des langage qu'on appelle fonctionnels.
Tout ce qui n'est pas strictement non impératif contient donc une certaine dose d'impératif (comme aurait dit Mr de La Palisse). Elle se traduit par des création (ouvertures, allocations, etc... ) , destructions (fermetures, désallocations, etc...) et des écritures (affectations de variables, écriture dans des connexions, etc...) et des lectures (lectures de contenus de variables, tableaux, connexions, ...) Toutes ces opérations sont non déterministes car leur sens précis (leur sémantique) dépend de l'état de ces données concrètes au moment de l'opération.
Un langage comme C est fortement impératif, car on est obligé de faire l'une des opérations non déterministes (= impératives) ci-dessus à presque chaque ligne de code.
Par ailleurs, le mot objet qu'on utilise en POO est essentiellement synonyme de donnée concrète. Un objet est avant tout une chose qu'on crée, qui change d'état dans le temps, et qu'on finit par détruire. Son comportement est typiquement non déterministe.
Bien entendu, la POO ne se limite pas aux objects, et certains des principes sur lesquels elle repose, sont tout aussi compatibles avec la programmation déterministe (le terme fonctionnel est impropre ici, même si elle se pratique surtout dans les langages fonctionnels). Ce sont le polymorphisme, l'encapsulation, l'héritage, l'asbtraction, la modularité.
L'affirmation qui est sous-jacente dans le premier post que la POO serait opposée à l'impératif pour des raisons de maintenance ne me semble pas exacte, les objets étant de nature concrète donc appelant donc l'impératif. Si la mainteanc est plus facile en POO, c'est pour des raisons qui n'ont rien à voir avec l'impératif. Ce sont les autres principes qui jouent. Toutefois, il est vrai que ce qui rend les meilleurs services pour la maintenance est d'éviter la programmation impérative autant que possible. Mais c'est autre chose que de programmer objet. C'est programmer déterministe. La raison principale est qu'il n'y a rien qui complique plus la sémantique (et rend donc les programmes incompréhensibles) que le non déterminisme.
Si mon baratin ne définit pas vraiment la POO (qui repose sur trop de principes pour qu'on puisse l'expliquer en une page), j'espère qu'il permet de comprendre ce qu'on entend par impératif.
