JMRI: Introduction to JMRI Library Structure

Because we expect to have different interfaces in the jmrix package, the JMRI tools don't directly create the interface objects they need. Rather, they ask for instances of interfaces. For interfaces in the jmri package, which might be implemented by lots of different layout types, jmri.InstanceManager satisfies these requests.

More information on how things (e.g. objects representing items on the layout) are named is available on a separate page.

More specifically:

jmri: contains interfaces and base class implementations for the common JMRI objects. This is the basic interface to the overall JMRI library and its capabilities. Code in the jmri package should depend on no other JMRI code, though it may depend on externals (log4j, etc)
jmrit: contains commonly useful tools and extensions. It can depend on jmri.* and externals. It must not depend on jmrix.*
jmrix: contains code that is specific to a particular external system. This includes implementations of jmri interfaces that are specific to a system, plus system-specific tools (in the long run, those could certainly be separated) jmrix can depend on jmri and externals, but not jmrit.
util: general service classes that are _not_ user level tools.
managers: Abstract and default implementations of the various JMRI type managers, e.g. the concrete classes from the InstanceManager. It's a historical accident that these have a package of their own, rather than being rolled into jmri.implementations.
implementations: Abstract and default implementations of the jmri objects; no system specific or Swing code allowed here. These are in a separate package, rather than in jmri itself, to make the jmri package simpler to understand for people who just want to use the library.
apps: contains application bases that can use jmri, jmrit, and jmrix classes, along with anything else. By having this here, we break the dependency between jmrix and jmrit classes (somebody has to create the general and system-specific tool objects for an application; that dependency is from the apps package)

Basically:


      apps   ->   jmri

                  A  A
                 /    \
                /      \
              jmrix     jmrit

(This should show apps using jmrit and jmrix also, but that's too hard to draw in ASCII)

Extensive use of Factory pattern via objects we call "Manager" objects.

Example: a Turnout

Turnouts involve:

Turnout - the basic interface. This is what you should expect to deal with when writing your layout automation code; its what you get when you make a request from the TurnoutManager, etc.
AbstractTurnout - provided for convenience when implementing the Turnout interface for specific hardware, this provides the basic implementation.
LnTurnout - a specific implementation for LocoNet-connected turnouts.

To get a specific Turnout instance that represents something on the layout, you make a request of a TurnoutManager. This is also an interface, with a similar implementation pattern.