Conventions pour simplifier le développement et l'utilisation des composants

Cette note technique décrit la manière dont l'emploi de conventions de nommage des méthodes peut simplifier l'écriture, la maintenance, et l'utilisation des composants. La stratégie décrite trie les méthodes dans le code source et le composant final afin de les répartir dans les catégories publique, protégée et privée, définies dans 4D Insider.

Une documentation complète sur les composants 4D se trouve dans l'Addendum pour 4D Insider v 6.7 et le manuel de référence pour 4D Insider 6.8.

Les composants 4D constituent un moyen pratique de grouper et de distribuer du code pour une réutilisation dans plusieurs bases de données ou par différents développeurs. Outre une simplification dans l'installation et la mise à jour du code, les composants peuvent également réduire la complexité apparente d'un système en cachant les méthodes et autres objets. Par exemple, un système pourra se composer de 200 méthodes en interne et en exposer seulement 20 aux développeurs. Un programmeur utilisant le composant bénéficie des fonctionnalités des 200 méthodes tout en ayant seulement à apprendre à en utiliser 20.

Les composants sont définis dans 4D Insider. Chaque objet ajouté au composant doit être affecté à l'un des trois dossiers automatiquement définis par 4D Insider : public, protégé ou privé, représentant trois niveaux différents de protection.

Ci-dessous, voici comment sont organisés ces trois dossiers dans 4D Insider :

Une fois un composant défini, 4D Insider peut générer un fichier d'installation du composant à partir des objets originaux de la base de données source. Le composant peut ensuite être installé dans un nombre indéterminé de bases cibles. Dans la base de données source, l'affectation à un dossier n'a aucun impact sur la manière dont le code apparaît ou est exécuté. Dans la base de données cible, en revanche, cette affectation entraîne une grande différence.

Ci-dessous nous reprenons un résumé des principales propriétés de chaque dossier :

Privé
· L'objet ne peut pas être vu du tout.

Protégé
· Le nom de l'objet est visible.
· L'objet ne peut pas être renommé ou supprimé.
· Le code de l'objet ne peut pas être vu ou édité.
· Le code de l'objet peut comprendre des appels aux objets privés.

Public
· Le nom de l'objet est visible.
· L'objet ne peut pas être renommé ou supprimé.
· Le code de l'objet peut être vu ou édité.

Le code de l'objet ne peut comprendre des appels aux objets privés.

Ces règles sont vérifiées dans la base source par 4D, 4D Insider et Sanity Check. Par exemple, les méthodes privées ne sont pas montrées, et les méthodes protégées ne peuvent être renommées ou vues.

Dans 4D Insider, le niveau de protection de chaque objet visible est clair, à la fois dans le code de la base source et dans celui de la base cible. Malheureusement, ce n'est pas le cas à l'intérieur de 4D. Voici, par exemple, une liste de méthodes de la base source pour un hypothétique composant de gestion de journal (NDT : Log Management ).

Dans le code de la base source, il n'y a aucun moyen de voir si une méthode est privée, protégée ou publique. Cela peut se révéler ennuyeux, car rien ne vous empêche d'effectuer des appels vers des méthodes privées depuis des méthodes publiques, ce qui est interdit dans le composant final. 4D Insider détecte cette erreur, mais seulement une fois que vous quittez 4D et basculez vers le système de définition d'un composant par 4D Insider.

La fenêtre de l'explorateur dans la base cible utilise un indice visuel pour distinguer les méthodes publiques et protégées, comme montré ci-dessous :

Cette indication est utile, mais elle est petite, et passe facilement inaperçue dans une longue liste de méthodes. De plus, elle n'est pas représentée dans le code lui-même. Dans cette méthode par exemple, il n'y a aucun moyen de savoir si une méthode de la base cible est protégée ou publique :

Les méthodes LogManagerIsRunning et LogManagerStart sont protégées. Si vous essayez de les éditer, 4D affiche une alerte de ce type :

Une simple convention de nommage peut surmonter ou réduire les problèmes que nous venons de mentionner. Au travers d'un nommage structuré, les méthodes peuvent inclure un rappel de leur statut et se trier en accord avec leur niveau de protection. Ces caractéristiques s'appliquent aussi bien au code de la base source qu'à celui de la base cible. Voici un résumé d'un exemple de convention de nommage :

   Préfixe du composant + {indicateur de protection} + nom descriptif

En l'appliquant à notre exemple de composant hypothétique de gestion de journal, les règles de nommage pourraient se présenter ainsi :

· Préfixe : LogManager ;
· Privé : pas de caractère spécial ;
· Protégé : caractère de soulignement ( underscore) ;
· Publique : espace.

Ce qui donne sur un échantillon de noms de méthodes :

· Privé
LogManagerCloseLog
LogManagerOpenLog
· Protégé
LogManager_Initialize
LogManager_Start
· Publique
LogManager Setup

Maintenant, les noms de méthodes sont triés de manière signifiante par 4D et 4D Insider. Ci-dessous, une illustration du code de la base source dans l'explorateur lorsque ces règles de nommage sont appliquées :

Avec un schéma de nommage comme celui présenté dans cette note, la vérification de l'affectation correcte des méthodes au dossier correspondant de 4D Insider devient une simple vérification visuelle. Dans l'exemple ci-dessous, il est facile de voir que la routine LogManager_Start se trouve dans un mauvais dossier :

La convention utilisée dans cette note n'est pas la seule qui fonctionne. Vous pourriez préférer, par exemple, utiliser un préfixe différent pour toutes les méthodes d'un niveau de protection équivalent ou choisir différents caractères pour séparer le préfixe et la partie descriptive du nom. L'un des bénéfices des choix spécifiques retenus ici se traduit par l'apparition des méthodes publiques en tête de liste dans la base cible. Il devient ainsi plus facile à l'utilisateur du composant d'accéder aux routines qu'il peut éditer.

Les composants 4D représentent un moyen commode de regrouper et distribuer du code, tout en réduisant la complexité apparente du système en dissimulant la majeure partie du code. L'un des problèmes à résoudre dans l'emploi des composants réside dans le fait que les niveaux de protection n'apparaissent dans le code source de la base cible que sous la forme d'un petit indicateur visuel. Un nommage structuré peut réduire ou éliminer cette limitation en regroupant et en renforçant visuellement le niveau de protection de chaque objet appartenant au composant.