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 abstract implementations. It
  depends on no other JMRI code, though it may depends on
  externals (log4j, etc)

  jmrit contains commonly useful tools and extensions. It
  can depend on jmri.* and externals. In particular, some
  jmri.* implementations do live here.

  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.

  apps contains application bases that can use jmri, jrmix, and
  jrmix classes.  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.