JMRI: Patterns and Structure
Author: Bob Jacobsen
Keywords: JMRI technical code patterns structure

# JMRI: Modèles et Organisation

JMRI a grandi et évolué avec le temps, et vous ne pouvez pas toujours voir les structures et les caractéristiques actuellement préférées en regardant des morceaux de l'ancien code.

Cette page tente de décrire la structure et les modèles recommandés, et fournir des exemples des meilleures pratiques actuelles.

## Noms, NamedBeans, et les gestionnaires

Le concept "NameBean" est la base de JMRI. Un NamedBean est un objet de base qui représente quelque chose, typiquement quelque chose comme un Capteur ou un Aiguillage.

- Ils sont appelés "Bean" parce qu'ils sont une unité d'interaction: De multiples morceaux de code peuvent travailler avec l'un d'eux, il peut être chargé ou stocké, etc.
- Ils sont "named" parce que pour être sûr qu'ils sont uniques et retrouvables: Il y a seulement un Aiguillage NamedBean appelé LT01, et il représente un objet spécifique du réseau adressé( named ). Voir la page sur les Noms pour en savoir davantage.

Fonctionnellement, toutes les classes d'objets du système ( Capteur, Aiguillage,... ) et leurs mise en oeuvre spécifiques ( LnSensor, XNetTurnout, ...), hérite de la classe de base NamedBean.

Pour obtenir l'accès à un objet spécifique (un NamedBean d'un type spécifique avec un nom spécifique ), vous faites des demandes à un gestionnaire: vous demandez un TurnoutManager pour un Aiguillage spécifique à votre tour, vous accédez aux gestionnaires à travers l'InstanceManager commun.

Un utilisateur peut vouloir rééférencer un NamedBean via un nom utilisateur, et à son tour peut vouloir changer le NetBean spécifique auquel le nom utilisateur se réfère. "Yard East Turnout" peut être "LT12" à un point et plus tardpeut changer en "CT5". Pour gérer ceci, votre code utilise les objets NamedBeanHandle pour gérer les références pour NamedBeans. Ils automatisent le processus de renommage.

## Organisation du Code

Au plus haut niveau, nous séparons le code de test du code distribué en les mettant dans des répertoires distincts dans le répertoire de développement: "test" et "src". Il est donc facile de compiler une version sans code de test, d'appliquer des outils différents pour les deux types de code, etc

Dans le code source lui-même, nous séparons plusieurs types.

Le paquet jmri
  contient les interfaces de base pour le système. Il doit contenir le code de mise en œuvre minimale, et pas de références non-JMRI, en particulier le code Swing.
Le paquet jmri.jmris
  Contient tout le code pour la mise en œuvre des serveurs pour les interfaces JMRI.
Le paquet jmri.jmrit
  contient tout le code pour les outils JMRI non spécifiques au système et extensions La plupart des outils sont dans des sous-paquets, mais certains apparaissent directement dans le paquet
Le paquet jmri.jmrix
  Contient tout le code pour se connecter à du matériel spécifique du réseau ferré.
Les paquetsjmri.managers et jmri.implementations
  Ceux-ci fournissent des mises en œuvres par défaut pour les gestionnaires et les autres classes. Cela déplace le code du paquet primaire JMRI. Ils ne doivent pas répondre à des applications, jmri.jmrix ou jmri.jmrit.
paquet jmri.util
  Autres mise en oeuvre courantes d'usage général. Ne devrait pas dépendre des paquets jmri.jmrit ou jmri.jmrix. Le sous-paquet jmri.util.swing fournit les utilitaires Swing
paquet Apps
  Pour rassembler une application, cela peut dépendre de n'importe quoi.
Sous-répertoires configurexml
  Ceux-ci contiennent le code pour le système de configuration XML les paquets de haut niveau, esp util & dependancies, apps.
Sous-répertoires swing
  Contient les outils Swing spécifiques. En particulier à l'extérieur du paquet jmri.jmrit, nous essayons de séparer le code Swing du code normal opérationnel. Voir la page Swing pour plus d'informations.
Help files (fichiers d'aide)
  La structure du fichier d'aide, les fichiers échos de la structure du code. Pour plus d'informations, voir la page d'aide dans les pages JavaHelp.
ResourceBundles
  Nous utilisons le regroupements de ressources pour l'internationalisation. Elles sont colocalisée avec le code qui les référence, mais nous nous dirigeons vers une nouvelle convention de dénomination. Pour réduire le fardeau de chargement, nous nous dirigeons vers un modèle où le fichier jmri.foo.FooBundle.properties est adressé par un élément statique dans la classe jmri.foo.FooBundle, séparé des propriétés du fichier lui même. Cela réduit beaucoup le temps de chargement!
  Notez qu'il existe également quelques regroupements de ressources qui sont utilisés à d'autres fins, indiqués dans leurs commentaires en tête.

Le script outil de développement "checkdepends.csh" est destiné à vérifier certaines des dépendances par inadvertance, mais nous sommes loin de l'effacer.