|
Cette affirmation est inexacte. Les composants de contrôle sont absolument nécessaires dans les logiciels traditionnels (procéduraux, structurés) et dans les logiciels orientés objet. La manière dont ils sont mis en œuvre et conceptualisés peut différer, mais leur rôle fondamental reste le même :gérer le flux d'exécution et coordonner les interactions entre les différentes parties du système.
Voici une répartition :
Logiciel traditionnel (procédural/structuré) :
* Structures de contrôle explicites : Les composants de contrôle sont souvent très explicites dans la programmation procédurale. Des éléments tels que les instructions « if-else », les boucles « for » et « while », les instructions « goto » (bien que déconseillées) et les appels de fonction dictent directement le flux d'exécution. Le programmeur contrôle directement la séquence des opérations.
* Variables globales et données partagées : Le contrôle est souvent exercé en manipulant des variables globales ou des structures de données partagées. Une partie du programme peut modifier une variable globale, déclenchant un changement dans le comportement d'une autre partie. Cela peut entraîner une complexité et des difficultés dans la gestion du flux de contrôle.
* Sous-programmes/Fonctions : Les fonctions agissent comme des composants de contrôle en encapsulant une tâche spécifique et en contrôlant l'exécution au sein de cette tâche. Toutefois, le flux global reste largement dicté par la structure principale du programme.
Logiciel orienté objet :
* Contrôle implicite via les interactions d'objets : Le flux de contrôle dans les logiciels orientés objet est souvent moins explicite et plus implicitement défini à travers les interactions entre les objets. Les objets s'envoient des messages, déclenchant des méthodes (fonctions au sein des objets). La séquence de ces interactions détermine le déroulement global du programme.
* Programmation basée sur les événements : De nombreux systèmes orientés objet utilisent des architectures basées sur les événements. Les événements (tels que les clics des utilisateurs, les messages réseau, les expirations de minuterie) déclenchent des actions dans les objets. Le flux de contrôle est piloté par ces événements externes plutôt que par une séquence linéaire dictée par le programmeur.
* Modèles de conception : Les modèles de conception orientés objet, tels que les modèles d'état, de stratégie et de commandement, fournissent des moyens structurés pour gérer et contrôler le flux d'exécution au sein d'un système. Ceux-ci agissent comme des mécanismes de contrôle de niveau supérieur.
* Concurrence et multithreading : Les systèmes orientés objet exploitent souvent des threads ou des processus, nécessitant des mécanismes (comme les mutex, les sémaphores) pour contrôler l'accès simultané aux ressources partagées et gérer la synchronisation, qui sont des composants de contrôle cruciaux.
La différence clé :
La différence n'est pas l'*absence* de composants de contrôle, mais plutôt le *niveau d'abstraction* et la manière dont le contrôle est *distribué*. En programmation procédurale, le contrôle est souvent centralisé et explicite. Dans la programmation orientée objet, le contrôle est plus décentralisé et implicite, réparti entre les objets en interaction. Cependant, le besoin de mécanismes permettant de gérer l’ordre des opérations et des interactions reste fondamental.
En résumé, les deux paradigmes nécessitent des mécanismes pour contrôler le flux d’exécution. La programmation orientée objet déplace simplement l'attention des structures de contrôle explicites et centralisées vers un contrôle implicite et distribué via les interactions d'objets et la gestion des événements. Le besoin sous-jacent de gérer le flux des programmes reste cependant constant.
|
