JMRI: Introduction à la Structure de la Librairie de JMRI
Parce que nous nous attendons à avoir des interfaces différentes dans le paquet
jmrix
,
les outils JMRI
ne créez pas directement les objets d'interface dont ils ont besoin.
Plutôt, ils demandent des exemples
d'interfaces.
Pour les interfaces dans le paquet
jmri
, qui pourraient être mises en oeuvre
par beaucoup de types de réseaux différents,
jmri.InstanceManager
répond à ces demandes.
Plus d'informations sur la façon dont les choses (par exemple des objets représentant les éléments sur ler éseau)
sont nommées et
sont disponibles sur une page séparée .
Plus précisément:
- jmri
- Contient des interfaces et implémentations de classe de base
pour les objets communs JMRI. Ceci est l'interface de base
de la bibliothèque globale JMRI et de ses capacités.
Le Code dans le paquet jmri
devrait dépendre d'aucun autre code JMRI, mais il peut dépendre de
code externes (log4j, etc)
- jmrit
- Contient des outils utiles et des extensions communément utiles.
Il peut dépendre de jmri.* et externes. Il ne doit pas dépendre de jmrix.*
- jmrix
- Contient le code qui est spécifique à un système
externe particulier. Cela inclut les implémentations des interfaces de jmri
qui sont spécifiques à un système, plus les outils systéme spécifiques (à long terme, ceux-ci pourraient certainement être séparées).
jmrix peut dépendre de jmri et d'externes, mais pas de jmrit.
- util
- Classes de services général qui ne sont_pas_des outils au niveau de l'utilisateur.
- gestionnaires (managers)
- Résumé et implémentations par défaut des différents
type de Gestionnaires JMRI, par exemple, les classes concrètes de l'InstanceManager.
Il s'agit d'un accident de l'histoire que ceux-ci aient leurs propres paquets,
plutôt que d'être incorporés dans jmri.implementations.
- implémentations
- Résumé et implémentations par défaut des différents objets jmri;
pas de code système spécifique ou code Swing permis ici.
Ils sont dans un paquet séparé, plutôt que dans jmri lui-même,
pour rendre le paquet jmri simple à comprendre pour les personnes
qui veulent juste utiliser la bibliothèque.
- applications (apps)
- Contient les bases de l'application qui peut utiliser les classes jmri, jmrit, et
jmrix , ainsi que toute autre chose.
En ayant cela ici, nous brisons la dépendance
entre les classes et jmrix jmrit (quelqu'un doit créer les
objets outil généraux et spécifiques au système pour une application;
que la dépendance est du paquet apps)
Basiquement
apps -> jmri
A A
/ \
/ \
jmrix jmrit
(Cela devrait montrer des applications en utilisant jmrit et jmrix aussi, mais c'est trop difficile à dessiner en ASCII)
L'utilisation intensive du pattern Factory via des objets que nous appelons "gestionnaire" des objets.
L'utilisation intensive du pattern Factory via des objets
que nous appelons "gestionnaire" des objets.
Exemple: un Aiguillage
Les Aiguillages impliquent:
- aiguillage - l'interface de base. C'est ce que vous devriez vous attendre à trouver
lorsque vous écrivez votre code d'automatisation du réseau, c'est ce que vous obtenez
lorsque vous faites une demande du TurnoutManager, etc
- AbstractTurnout - fournit pour la commodité lors de l'implémentation de l'interface de l'aiguillage
pour du matériel spécifique, ceci offre la mise en oeuvre de base .
- LnTurnout - une implémentation spécifique pour les aiguillages LocoNet - connectés.
Pour obtenir une exemple d'Aiguillage spécifique qui représente quelque chose sur le réseau, vous
faite une demande au TurnoutManager.
Il s'agit également d'une interface, avec une implémentation
semblable du modèle.
- AbstractTurnout - fournit pour la commodité lors
de l'implémentation de l'interface de l'aiguillage
pour du matériel spécifique, ceci offre la
mise en oeuvre de base .
- LnTurnout - une implémentation spécifique
pour les aiguillages LocoNet - connectés.
Pour obtenir une exemple d'Aiguillage spécifique
qui représente quelque chose sur le réseau,
vous faite une demande au TurnoutManager. Il s'agit
également d'une interface, avec une
implémentation semblable du modèle.