Developpez.com - 4D
X

Choisissez d'abord la catégorieensuite la rubrique :


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

Date de publication : Août 2003

Par David ADAMS
 

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.

I. Résumé
II. Présentation
III. Privé, protégé et public
IV. Le problème : rendre visible dans 4D la protection des objets
V. La solution : grouper les méthodes visuellement au travers du nommage
VI. Bénéfice additionnel : vérification des affectations dans Insider
VII. Retenir un schéma de nommage
VIII. Conclusion


I. Résumé

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.


II. Présentation

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.


III. Privé, protégé et public

Les composant 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érent de protection.

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

Pictures 0599x0163


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.


IV. Le problème : rendre visible dans 4D la protection des objets

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 ).

Pictures 0211x0454


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 :

Pictures 0241x0120


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 :

Pictures 0436x0174


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

Pictures 0284x0147


V. La solution : grouper les méthodes visuellement au travers du nommage

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 :

Pictures 0185x0380


VI. Bénéfice additionnel : vérification des affectations dans Insider

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 :

Pictures 0231x0301


VII. Retenir un schéma de nommage

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érent 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.

Pictures 0321x0460


VIII. Conclusion

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.

__________________________________________________
Copyright © 1985-2009 4D SA - Tous droits réservés
Tous les efforts ont été faits pour que le contenu de cette note technique présente le maximum de fiabilité possible.
Néanmoins, les différents éléments composant cette note technique, et le cas échéant, le code, sont fournis sans garantie d'aucune sorte. L'auteur et 4D S.A. déclinent donc toute responsabilité quant à l'utilisation qui pourrait être faite de ces éléments, tant à l'égard de leurs utilisateurs que des tiers.
Les informations contenues dans ce document peuvent faire l'objet de modifications sans préavis et ne sauraient en aucune manière engager 4D SA. La fourniture du logiciel décrit dans ce document est régie par un octroi de licence dont les termes sont précisés par ailleurs dans la licence électronique figurant sur le support du Logiciel et de la Documentation afférente. Le logiciel et sa documentation ne peuvent être utilisés, copiés ou reproduits sur quelque support que ce soit et de quelque manière que ce soit, que conformément aux termes de cette licence.
Aucune partie de ce document ne peut être reproduite ou recopiée de quelque manière que ce soit, électronique ou mécanique, y compris par photocopie, enregistrement, archivage ou tout autre procédé de stockage, de traitement et de récupération d'informations, pour d'autres buts que l'usage personnel de l'acheteur, et ce exclusivement aux conditions contractuelles, sans la permission explicite de 4D SA.
4D, 4D Calc, 4D Draw, 4D Write, 4D Insider, 4ème Dimension ®, 4D Server, 4D Compiler ainsi que les logos 4e Dimension, sont des marques enregistrées de 4D SA.
Windows,Windows NT,Win 32s et Microsoft sont des marques enregistrées de Microsoft Corporation.
Apple, Macintosh, Power Macintosh, LaserWriter, ImageWriter, QuickTime sont des marques enregistrées ou des noms commerciaux de Apple Computer,Inc.
Mac2Win Software Copyright © 1990-2002 est un produit de Altura Software,Inc.
4D Write contient des éléments de "MacLink Plus file translation", un produit de DataViz, Inc,55 Corporate drive,Trumbull,CT,USA.
XTND Copyright 1992-2002 © 4D SA. Tous droits réservés.
XTND Technology Copyright 1989-2002 © Claris Corporation.. Tous droits réservés ACROBAT © Copyright 1987-2002, Secret Commercial Adobe Systems Inc.Tous droits réservés. ACROBAT est une marque enregistrée d'Adobe Systems Inc.
Tous les autres noms de produits ou appellations sont des marques déposées ou des noms commerciaux appartenant à leurs propriétaires respectifs.
__________________________________________________
 



Valid XHTML 1.1!Valid CSS!

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
Contacter le responsable de la rubrique 4D