Modèle de programmation

  • Article

Dans les premiers jours de la programmation par ordinateur, chaque programme était écrit comme un grand segment monolithique, rempli d’instructions goto . Chaque programme devait gérer ses propres entrées et sorties sur différents appareils matériels. À mesure que la discipline de programmation a mûri, ce code monolithique a été organisé en procédures, les procédures les plus couramment utilisées étant emballées dans les bibliothèques pour le partage et la réutilisation.

instructions goto monolithiques par rapport aux procédures empaquetées dans des bibliothèques partagées

Le langage de programmation C prend en charge la programmation orientée procédure. Dans C, la procédure main concerne toutes les autres procédures sous forme de zones noires. Par exemple, la procédure main ne peut pas déterminer comment les procédures A, B et X effectuent leur travail. La procédure main appelle uniquement une autre procédure ; elle n’a aucune information sur la façon dont cette procédure est implémentée.

isolation des activités effectuées dans des procédures externes

Les langages de programmation orientés procédure fournissent des mécanismes simples pour spécifier et écrire des procédures. Par exemple, le prototype de fonction C standard ANSI est une construction utilisée pour spécifier le nom d’une procédure, le type du résultat qu’elle retourne (le cas échéant) et le nombre, la séquence et le type de ses paramètres. L’utilisation du prototype de fonction est un moyen formel de spécifier une interface entre des procédures.

Microsoft RPC s’appuie sur ce modèle de programmation en permettant aux procédures, regroupées dans des interfaces, de résider dans des processus différents de ceux de l’appelant. Microsoft RPC ajoute également une approche plus formelle de la définition de procédure qui permet à l’appelant et à la routine appelée d’adopter un contrat pour l’échange de données à distance et l’appel de fonctionnalités. Dans le modèle de programmation Microsoft RPC, les appels de fonction traditionnels sont complétés par deux éléments supplémentaires.

  • Le premier élément est un fichier .idl/.acf qui décrit précisément l’échange de données et le mécanisme de passage de paramètres entre l’appelant et la procédure appelée.
  • Le deuxième élément est un ensemble d’API d’exécution qui fournissent aux développeurs un contrôle granulaire de l’appel de procédure distante, y compris les aspects de sécurité, la gestion de l’état sur le serveur, la spécification des clients qui peuvent communiquer avec le serveur, etc.