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.

Exemples

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.

Effet

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.

Usages appropriés

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.

Exemple

Au lieu d'une table par entité, tout est rangé dans une table générique entité–attribut–valeur, et l'application doit reconstruire ce que la base de données fournit déjà : types, contraintes et jointures. Même un filtre simple exige une auto-jointure et une conversion de type, et rien n'empêche un client de n'avoir aucune adresse e-mail ou un plafond de crédit négatif.

import sqlite3

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE entity (id INTEGER, attr TEXT, value TEXT)")


def save_customer(cid, name, email, credit_limit):
    db.executemany(
        "INSERT INTO entity VALUES (?, ?, ?)",
        [(cid, "name", name), (cid, "email", email), (cid, "credit_limit", str(credit_limit))],
    )


def customers_over(limit):
    return db.execute(
        "SELECT n.id, n.value FROM entity n "
        "JOIN entity c ON c.id = n.id AND c.attr = 'credit_limit' "
        "WHERE n.attr = 'name' AND CAST(c.value AS REAL) > ?",
        (limit,),
    ).fetchall()

Un vrai schéma permet au SGBDR d'imposer les types et les contraintes, d'utiliser un index et d'optimiser la requête : l'application ne réimplémente plus la plateforme sur laquelle elle s'exécute.

import sqlite3

db = sqlite3.connect(":memory:")
db.execute(
    "CREATE TABLE customer ("
    " id INTEGER PRIMARY KEY,"
    " name TEXT NOT NULL,"
    " email TEXT NOT NULL UNIQUE,"
    " credit_limit REAL NOT NULL CHECK (credit_limit >= 0))"
)
db.execute("CREATE INDEX customer_credit_limit ON customer (credit_limit)")


def save_customer(cid, name, email, credit_limit):
    db.execute("INSERT INTO customer VALUES (?, ?, ?, ?)", (cid, name, email, credit_limit))


def customers_over(limit):
    return db.execute("SELECT id, name FROM customer WHERE credit_limit > ?", (limit,)).fetchall()

Adapté de l’article Wikipédia “Inner-platform effect” (révision 1319593770), disponible sous licence CC BY-SA 4.0 ; le texte a été traduit et modifié, et des exemples ont été ajoutés.