Package jmri.managers

Class AbstractProvidingProxyManager<E extends NamedBean>

Type Parameters:
E - the supported type of NamedBean
All Implemented Interfaces:
PropertyChangeListener, EventListener, PropertyChangeFirer, PropertyChangeProvider, SilenceablePropertyChangeProvider, VetoableChangeFirer, VetoableChangeProvider, Manager<E>, Manager.ManagerDataListener<E>, ProvidingManager<E>, ProxyManager<E>
Direct Known Subclasses:
ProxyIdTagManager, ProxyLightManager, ProxyReporterManager, ProxySensorManager, ProxyTurnoutManager

public abstract class AbstractProvidingProxyManager<E extends NamedBean>
extends AbstractProxyManager<E>
implements ProvidingManager<E>
Implementation of a Manager that can serves as a proxy for multiple system-specific implementations.

Automatically includes an Internal system, which need not be separately added any more.

Encapsulates access to the "Primary" manager, used by default, which is the first one provided.

Internally, this is done by using an ordered list of all non-Internal managers, plus a separate reference to the internal manager and default manager.

  • Constructor Details

  • Method Details

    • provideNamedBean

      protected E provideNamedBean​(String name) throws IllegalArgumentException
      Locate via user name, then system name if needed. If that fails, create a new NamedBean: If the name is a valid system name, it will be used for the new NamedBean. Otherwise, the makeSystemName method will attempt to turn it into a valid system name. Subclasses use this to create provider methods such as getSensor or getTurnout via casts.
      Parameters:
      name - the user name or system name of the bean
      Returns:
      an existing or new NamedBean
      Throws:
      IllegalArgumentException - if name is not usable in a bean
    • newNamedBean

      public E newNamedBean​(String systemName, String userName)
      Return an instance with the specified system and user names. Note that two calls with the same arguments will get the same instance; there is i.e. only one Sensor object representing a given physical sensor and therefore only one with a specific system or user name.

      This will always return a valid object reference for a valid request; a new object will be created if necessary. In that case:

      • If a null reference is given for user name, no user name will be associated with the NamedBean object created; a valid system name must be provided
      • If a null reference is given for the system name, a system name will _somehow_ be inferred from the user name. How this is done is system specific. Note: a future extension of this interface will add an exception to signal that this was not possible.
      • If both names are provided, the system name defines the hardware access of the desired turnout, and the user address is associated with it.
      Note that it is possible to make an inconsistent request if both addresses are provided, but the given values are associated with different objects. This is a problem, and we don't have a good solution except to issue warnings. This will mostly happen if you're creating NamedBean when you should be looking them up.
      Parameters:
      systemName - the system name
      userName - the user name
      Returns:
      requested NamedBean object (never null)
    • makeBean

      protected abstract E makeBean​(Manager<E> manager, String systemName, String userName)
      Defer creation of the proper type to the subclass.
      Parameters:
      manager - the manager to invoke
      systemName - the system name
      userName - the user name
      Returns:
      a bean