Programmation basée sur l'interface - Interface-based programming


La programmation basée sur l'interface , également connue sous le nom d' architecture basée sur l'interface , est un modèle architectural pour la mise en œuvre de la programmation modulaire au niveau des composants dans un langage de programmation orienté objet qui n'a pas de système de module. Un exemple d'un tel langage est Java , qui (à partir de 2015), n'a pas de système de modules au niveau des composants. Java a un système de packages , mais les composants logiciels Java se composent généralement de plusieurs packages Java  - et dans tous les cas, la programmation d'interface peut offrir des avantages par rapport à la simple utilisation de packages Java, même si un composant ne consiste qu'en un seul package Java.

La programmation basée sur l'interface définit l'application comme une collection de composants, dans laquelle les appels de l' interface de programmation d'application (API) entre les composants ne peuvent être effectués que via des interfaces abstraites, et non des classes concrètes. Les instances de classes seront généralement obtenues via d'autres interfaces en utilisant des techniques telles que le modèle Factory .

Ceci est censé augmenter la modularité de l'application et donc sa maintenabilité . Cependant, une certaine prudence s'impose: le simple fait de diviser une application en composants arbitraires communiquant via des interfaces ne garantit pas en soi un couplage faible ou une cohésion élevée , deux autres attributs généralement considérés comme essentiels pour la maintenabilité.

Une architecture basée sur une interface peut être utilisée lorsque des tiers - ou même des équipes distinctes au sein d'une même organisation - développent des composants ou des plugins supplémentaires pour un système établi. La base de code de l' EDI Eclipse est un exemple de programmation basée sur une interface. Les fournisseurs de plug-ins Eclipse doivent simplement développer des composants qui satisfont l'interface spécifiée par le fournisseur de l'application parent, la Fondation Eclipse. En effet, dans Eclipse, même les composants d'origine tels que les outils de développement Java sont eux - mêmes des plugins. C'est un peu comme un fabricant de téléphone portable spécifiant une interface de chargeur mobile (disposition des broches, tension de courant continu attendue , etc.) et le fabricant et les tiers fabriquant leurs propres chargeurs de téléphone portable conformes à cette spécification d'interface standard.

Évolution du logiciel dans la programmation basée sur l'interface

L'utilisation d' interfaces pour permettre à des équipes disparates de collaborer soulève la question de savoir comment les changements d'interface se produisent dans la programmation basée sur l'interface. Le problème est que si une interface est modifiée, par exemple en ajoutant une nouvelle méthode, l'ancien code écrit pour implémenter l'interface ne se compilera plus - et dans le cas de plugins chargés dynamiquement ou liés, soit échouera à charger ou à lier, ou crash lors de l'exécution. Il existe deux approches de base pour traiter ce problème:

  1. une nouvelle interface peut être développée avec des fonctionnalités supplémentaires, qui pourraient hériter de l'ancienne interface
  2. une politique de versionnage de logiciel telle que le versionnage sémantique 2.0 peut être communiquée aux implémenteurs d'interface, pour permettre des changements incompatibles en avant, voire incompatibles en arrière, dans les futures versions "majeures" de la plateforme

Ces deux approches ont été utilisées dans la plate-forme Java.

Conception par contrat

L'éditeur des interfaces promet généralement de ne pas modifier l'interface dans les nouvelles versions «mineures» du logiciel, et l'implémenteur, en implémentant l'interface, implique qu'il a implémenté au moins les parties requises de l'interface sans aucune déviation. Une interface peut donc être considérée comme un «accord contractuel» - entre un fournisseur et un consommateur de l'interface. Si ce contrat est documenté de manière plus formelle sous la forme d'une spécification logicielle, il s'agit d'un exemple de conception par contrat . Cependant, la conception par contrat en soi n'impose pas l'utilisation d'interfaces pour tous les composants.

Voir également

  • Microservices
  • Modèle d'acteur
  • CORBA , un ancien système basé sur des composants pour les logiciels orientés objet qui est maintenant rarement utilisé, pour diverses raisons

Les références