Una factoría de estado implementa el interface StateFactory o DirStateFactory.

StateFactory tiene un método: getStateToBind().

DirStateFactory es un subinterface de StateFactory y declara un método adicional:getStateToBind():

Este método acepta como un argumento el objeto a unir (obj).

Los argumentos name y nameCtx se le proporcionan a la factoría de estado en caso de que ésta requiera información adicional. El argumento env son las propiedades de entorno del contexto que está usando la factoría de estado. La versión DirStateFactory del método acepta un argumento adicional inAttrs (Attributes), que contiene los atributos a unir con el objeto obj.

Deberíamos usar un StateFactory con un contexto que implemente el interface Context.

Usaremos DirStateFactory con un contexto que implemente el interface DirContext.

Por ejemplo, un proveedor de servicios de nombres COS sólo implementa el interface Context. Como no se le van a pasar argumentos Attributes al proveedor de servicios, y consecuentemente tampoco a la factoría de estado, el proveedor de servicio sólo usara getStateToBind() como se define en el interface StateFactory. Por el contrario, el proveedor de servicio LDAP normalmente implementa el interface DirContext y usará getStateToBind() como se define en el interface DirStateFactory.

La clase de la factoría de estado no sólo debe implementar los interfaces StateFactory/DirStateFactory y proporcionar implementación para los métodos getStateToBind().

También debe ser pública e tener un constructor público que no acepte argumentos.

Normalmente, una factoría de estado es bastante simple y pequeña. Su papel principal es realizar alguna transformación de la entrada y producir un objeto (y/o atributos) capaces de ser almacenados por el proveedor de servicios. Por ejemplo, una factoría de estado para un proveedor LDAP podría aceptar un objeto y algunos atributos y devolver un conjunto de atributos que sean la unión entre los atributos de entrada y los atributos que representan el objeto.

Una factoría de estado para un proveedor de servicio de nombres COS, por ejemplo, acepta un objeto java.rmi.Remote y devuelve su objeto tie(vínculo) CORBA.

En general, existe una relación muy cerrada entre la representación del objeto que es almacenado en el servicio de nombres o directorio subyacente y la factoría de estado que hace la transformación. Por ejemplo, si un objeto está representado por un conjunto de atributos en un directorio, la correspondiente factoría de estado debería devolver atributos para representar el objeto.

Una factoría de estado normalmente es muy específica con respecto a los tipos de transformaciones que maneja. Por ejemplo, una factoría podría aceptar objetos CORBA, mientras que otra sólo podría aceptar objetos que implementen un interface específico. De echo, en muchos casos, como se esplica en la siguiente página, el JNDI le pedirá a un factoría de estado que intente la transformación usando entradas que estaban pensadas para otras factorías.

Es muy común que un sólo proveedor de serivicios use múltiples factorías de estado. Por lo tanto, si una factoría encuentra que no soporta el tipo de entrada suministrado, debería devolver null. La factoría sólo debería lanzar una excepción cuando encuentre un error procesando la entrada que por otro lado debería haber aceptado. Lanzar una excepción evita que se puedan intentar otras factorías de estados.