Package jmri.managers

Class AbstractMemoryManager

java.lang.Object
jmri.beans.PropertyChangeSupport
jmri.beans.VetoableChangeSupport
jmri.managers.AbstractManager<Memory>
jmri.managers.AbstractMemoryManager
All Implemented Interfaces:
PropertyChangeListener, VetoableChangeListener, EventListener, PropertyChangeFirer, PropertyChangeProvider, SilenceablePropertyChangeProvider, VetoableChangeFirer, VetoableChangeProvider, Manager<Memory>, MemoryManager, ProvidingManager<Memory>
Direct Known Subclasses:
DefaultMemoryManager
public abstract class AbstractMemoryManager
extends AbstractManager<Memory>
implements MemoryManager
Abstract partial implementation of a MemoryManager.

  • Constructor Details

  • Method Details

    • getXMLOrder

      public int getXMLOrder()
      Determine the order that types should be written when storing panel files. Uses one of the constants defined in this class.

      Yes, that's an overly-centralized methodology, but it works for now.

      Specified by:
      getXMLOrder in interface Manager<Memory>
      Returns:
      write order for this Manager; larger is later.

    • typeLetter

      public char typeLetter()
      Specified by:
      typeLetter in interface Manager<Memory>
      Returns:
      The type letter for a specific implementation

    • provideMemory

      @Nonnull public Memory provideMemory​(@Nonnull String sName)
      Get the Memory with the user name, then system name if needed; if that fails, create a new Memory. If the name is a valid system name, it will be used for the new Memory. Otherwise, the makeSystemName method will attempt to turn it into a valid system name.
      Specified by:
      provideMemory in interface MemoryManager
      Parameters:
      sName - User name, system name, or address which can be promoted to system name
      Returns:
      Never null

    • getMemory

      public Memory getMemory​(@Nonnull String name)
      Get an existing Turnout or return null if it doesn't exist. Locates via user name, then system name if needed.
      Specified by:
      getMemory in interface MemoryManager
      Parameters:
      name - User name or system name to match
      Returns:
      null if no match found

    • newMemory

      @Nonnull public Memory newMemory​(@Nonnull String systemName, @CheckForNull String userName)
      Return a Memory with the specified system and user names. Note that two calls with the same arguments will get the same instance; there is only one Memory object representing a given physical Memory and therefore only one with a specific system or user name.

      This will always return a valid object reference; 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 Memory object created; a valid system name must be provided
      • If both names are provided, the system name defines the hardware access of the desired Memory, and the user address is associated with it. The system name must be valid.
      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 Memory objects when you should be looking them up.
      Specified by:
      newMemory in interface MemoryManager
      Parameters:
      systemName - the system name
      userName - the user name
      Returns:
      requested Memory object (never null)

    • newMemory

      @Nonnull public Memory newMemory​(@Nonnull String userName)
      For use with User GUI, to allow the auto generation of systemNames, where the user can optionally supply a username.

      This will always return a valid object reference; a new object will be created if necessary. (If a null reference is given for user name, no user name will be associated with the Memory object created) 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 Memory objects when you should be looking them up.

      Specified by:
      newMemory in interface MemoryManager
      Parameters:
      userName - the user name
      Returns:
      requested Memory object (never null)

    • createNewMemory

      @Nonnull protected abstract Memory createNewMemory​(@Nonnull String systemName, @CheckForNull String userName)
      Internal method to invoke the factory, after all the logic for returning an existing Memory has been invoked.
      Parameters:
      systemName - Memory system name
      userName - Memory user name
      Returns:
      a new Memory

    • getBeanTypeHandled

      @Nonnull public String getBeanTypeHandled​(boolean plural)
      Get the user-readable name of the type of NamedBean handled by this manager.

      For instance, in the code where we are dealing with just a bean and a message that needs to be passed to the user or in a log.

      Specified by:
      getBeanTypeHandled in interface Manager<Memory>
      Parameters:
      plural - true to return plural form of the type; false to return singular form
      Returns:
      a string of the bean type that the manager handles, eg Turnout, Sensor etc

    • getNamedBeanClass

      public Class<Memory> getNamedBeanClass()
      Get the class of NamedBean supported by this Manager. This should be the generic class used in the Manager's class declaration.
      Specified by:
      getNamedBeanClass in interface Manager<Memory>
      Returns:
      the class supported by this Manager.

    • provide

      @Nonnull public Memory provide​(@Nonnull String name) throws IllegalArgumentException
      Description copied from interface: ProvidingManager
      Get an existing instance via user name, then system name; if no matching instance is found, create a new NameBean from the system name.

      If the name is a valid system name, it will be used for the new NamedBean. Otherwise, the Manager.makeSystemName(java.lang.String) method will attempt to turn it into a valid system name which the manager will attempt to use. If that fails, an exception is thrown.

      This is similar to the specific methods found in certain type-specific managers: TurnoutManager.provideTurnout(java.lang.String), SensorManager.provideSensor(java.lang.String), et al. Those might be more mnemonic; this one is more generic. Neither is preferred nor deprecated; use your choice.

      Specified by:
      provide in interface ProvidingManager<Memory>
      Parameters:
      name - User name, system name, or address which can be promoted to system name
      Returns:
      Never null
      Throws:
      IllegalArgumentException - if NamedBean doesn't already exist and the manager cannot create it due to an illegal name or name that can't be parsed.