différence de signification d'Interface dans le contexte d' API et interface en .Net (héritable)?

Je suis programmeur relativement junior (mais m’ y « connaissant pas trop mal en c#/.Net »),et en relisant un conséquent tutoriel sur le mode déconnecté d'ADO.NET, je suis tombé sur de la théorie concernant l’ »ancien » ADO ("tout court) faisant référence au concept d'"Interface de Programmation d'Application" (=>API)
dans le contexte suivant :

Citation:

---

...Non seulement il vous faut coder différentes méthodes d'accès aux données, mais encore toutes les interfaces de programmation d'application (API), les interfaces COM, les interfaces Automation et les interfaces procédurales vous empêchent d'utiliser les transactions comme méthode fiable...

---

Au final, ma question est de savoir si ce concept d'Interface employé dans le contexte d'une API a +/- la même signification qu'un autre concept d'Interface auquel je suis bcp plus familier, celui d'Interface du monde OO de c# .Net, à savoir

Citation:

---

que ce type d'interface représente finalement un contrat pour les classes qui en héritent qui doivent dès lors fournir une implémentation de chacune des méthodes ou propriétés définies(uniquement leur signature; pas d'implémentation) par l'interface; méthodes/propriétés qui étant Publics, peuvent donc aussi représenter une forme de "carte de visite" des classes qui en héritent et [b]par là même faciliter les interactions/la communication entre les (instances des) différentes classes

---

ce qui me fait qque part penser à l'idée que je me fait du sens d'une API, d'après ce que j'en ai lu.

Et, désolé d'avance pour la longueur du post, mais je voulais essayer d'être complet afin que qqun de plus expérimenté puisse infirmer ou confirmer mon "hypothèse" quant au sens de ce terme qui me "perturbe" ;))
Merci d'avance à tous...

Bonjour.

En réalité le concept d'interface (ou protocole en Objective-C) est bien antérieur à C# ou Java et désigne en programmation OO un type abstrait (qui ne contient aucune donnée et dont les méthodes ne sont que définies et pas implémentées). Ainsi en C++, malgré l'absence de support direct par le langage, on parle d'interface à propos d'une classe sans champs et dont les méthodes n'ont pas de corps et ont simplement pour adresse NULL (via la syntaxe : void someFunction() = 0;). Elles sont d'ailleurs typiquement préfixées par la lettre I, comme en C#, l'exemple le plus connu étant IUnknown, l'interface commune à tous les objets COM. Finalement les concepteurs de dotnet se sont contentés d'ajouter à leurs langages un mot-clé pour définir de façon stricte et explicite une interface en même temps qu'ils restreignaient l'héritage multiple, le faisant passer de N classes à 1 classe + N interfaces.

Tout ceci étant dit, revenons à ta question
* COM : ce sont bien des interfaces au sens OO, toutes basées sur l'interface IUnknown.
* Interfaces d'automation : ce sont des interfaces COM pour WMI donc même sens.
* Interfaces procédurales : là en revanche, non, on est typiquement dans le cadre de la programmation procédurale. Par exemple, au lieu d'implémenter une interface IFoo avec une méthode Bar, le développeur tiers enregistrera en C son composant en passant un pointeur vers une méthode ayant la signature Bar.
* API : ça dépend des API mais en général, pour Win32, c'est du procédural.