Effet de plateforme interne.

L’effet de plateforme interne est la tendance des architectes logiciels à créer un système si personnalisable qu’il finit par devenir une réplique, et souvent une mauvaise réplique, de la plateforme de développement logiciel qu’ils utilisent. Cela est généralement inefficace et de tels systèmes sont souvent considérés comme des exemples d’anti-patron.

On en trouve des exemples dans les logiciels reposant sur des greffons, comme certains éditeurs de texte et navigateurs web, qui amènent souvent les développeurs à créer des greffons recréant des logiciels qui s’exécuteraient normalement par-dessus le système d’exploitation lui-même. Le mécanisme de modules complémentaires de Firefox a servi à développer un certain nombre de clients FTP et de navigateurs de fichiers, qui reproduisent effectivement certaines fonctionnalités du système d’exploitation, quoique sur une plateforme plus restreinte.

Dans le monde des bases de données, les développeurs sont parfois tentés de contourner le SGBDR, par exemple en stockant tout dans une seule grande table à trois colonnes intitulées identifiant d’entité, clé et valeur. Si ce modèle entité-attribut-valeur permet au développeur de s’affranchir de la structure imposée par une base de données SQL, il en perd tous les avantages, puisque tout le travail que le SGBDR pourrait effectuer efficacement est reporté sur l’application. Les requêtes deviennent bien plus alambiquées, les index et l’optimiseur de requêtes ne peuvent plus fonctionner efficacement, et les contraintes de validité des données ne sont pas appliquées. Les performances et la maintenabilité peuvent être extrêmement mauvaises.

Une tentation similaire existe pour XML, où les développeurs privilégient parfois des noms d’éléments génériques et utilisent des attributs pour stocker l’information utile. Par exemple, chaque élément pourrait être nommé item et posséder les attributs type et value. Cette pratique nécessite des jointures sur plusieurs attributs afin d’en extraire le sens. Par conséquent, les expressions XPath sont plus alambiquées, l’évaluation est moins efficace et la validation structurelle n’apporte que peu d’avantages.

Un autre exemple est le phénomène des bureaux web, où tout un environnement de bureau—incluant souvent un navigateur web—s’exécute à l’intérieur d’un navigateur (lequel s’exécute lui-même généralement au sein de l’environnement de bureau fourni par le système d’exploitation). Un bureau dans un bureau peut être particulièrement malcommode pour l’utilisateur, et cela n’est donc généralement fait que pour exécuter des programmes qui ne peuvent pas être facilement déployés sur les systèmes des utilisateurs finaux, ou en masquant le bureau externe.

Il est normal que les développeurs logiciels créent une bibliothèque de fonctions personnalisées propres à leur projet. L’effet de plateforme interne survient lorsque cette bibliothèque s’étend pour inclure des fonctions à usage général qui dupliquent des fonctionnalités déjà disponibles au sein du langage de programmation ou de la plateforme. Comme chacune de ces nouvelles fonctions appelle généralement un certain nombre des fonctions d’origine, elles ont tendance à être plus lentes et, si elles sont mal codées, moins fiables également.

D’un autre côté, de telles fonctions sont souvent créées pour présenter une couche d’abstraction plus simple (et souvent plus portable) par-dessus des services de plus bas niveau qui, soit ont une interface peu commode, sont trop complexes, non portables ou insuffisamment portables, soit conviennent tout simplement mal au code applicatif de plus haut niveau.

Une plateforme interne peut s’avérer utile pour des raisons de portabilité et de séparation des privilèges—autrement dit, afin qu’une même application puisse s’exécuter sur une grande variété de plateformes externes sans rien affecter en dehors d’un bac à sable géré par la plateforme interne. Par exemple, Sun Microsystems a conçu la plateforme Java pour atteindre ces deux objectifs.