Una factoría de objetos implementa los interfaces ObjectFactory o DirObjectFactory.

ObjectFactory tiene un método: getObjectInstance().

DirObjectFactory es un subinterface de ObjectFactory y declara un método adicional: getObjectInstance().

Este método acepta como argumentos información sobre el objeto (info) y el nombre del objeto (name) en relación al contexto (nameCtx) en el que está unido. El argumento env son las propiedades de entorno para el contexto que está usando la factoría de objetos. La versión DirObjectFactory del método acepta un argumento adicional attrs (Attributes), que contiene (alguno o todos) los atributos asociados con obj.

Deberíamos usar un ObjectFactory con un contexto que implementa sólo el interface Context.

Usaremos un DirObjectFactory con un contexto que implementa el interface DirContext.

Por ejemplo, un proveedor de servicio de nombres COS sólo implementa el interface Context. Como los Attributes no son relevantes en este escenario, sólo el getObjectInstance() definido en el interface ObjectFactory es relevante para este proveedor de servicios. Por el contrario, un proveedor de servicios LDAP normalmente implementa el interface DirContext y usará getObjectInstance() según lo definido en el interface DirObjectFactory. El parámetro Attributes lo usa el proveedor de servicios para pasar cualquier atributo asociado con info a la factoría para que ésta no tenga que localizarlos por sí misma. Por ejemplo, cuando un proveedor de servicio hace una Context.lookup(), puede pasar a getObjectInstance() cualquier atributo que lea desde el servidor sobre el objeto que está siendo buscando.

La clase de la factoría de objetos no sólo debe implementar el interface ObjectFactory/DirObjectFactory y proporcionar una implementación de getObjectInstance().

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

Normalmente, una factoría de objetos es bastanse sencilla y pequeña. Su papel principal es recolectar la información necesaria para crear un ejemplar de la clase del objeto deseado y luego llamar al constructor de la clase. Sin embargo, la complejidad de los objetos que crea puede variar significativamente.

Por ejemplo, los ejemplos de factorías de ejemplos dadas en esta lección son bastante triviales; los objetos que crean también son triviales. Por el contrario, una factoría de ojetos LDAP crea un contexto LDAP, que crea y maneja conexiones a un servidor LDAP. En este caso, una factoría de objetos relativamente simple crea un objeto muy complejo.

En general, la información que usa una factoría de objetos para crear objetos sale del directorio. Consecuentemente, existe una estrecha relación entre la representación de los objetos almacenados en el directorio y la factoría de objetos que crea los objetos usando esta información. Por ejemplo, si el objeto está representado como una conjunto de atributos en el directorio, entonces la factoría de objetos correspondiente debe saber extraer la información desde esos atributos para crear el objeto.

Una factoría de objetos normalmente es muy especifica sin importar los tipos de transformaciones que manejará. De echo, en muchos casos, como se explicó en la sección Interacción entre Factorías de Objetos y Proveedores de Servicios, el JNDI le pedirá a una factoría de objetos que intente crear un ejemplar de un objeto que fue pensado para otra factoría de objetos. Un sólo proveedor de servicios normalmente usa varias factorías de objetos. Por lo tanto si una factoría de objetos encuentra que no puede crear un objeto basándose en los argumentos suministrados, debería devolver null.

Sólo si la factoría de objetos sabe con seguridad que está pensada para crear el objeto, pero no puede, debería lanzar una excepción. Lanzar una excepción evita que otras factorías de objetos lo intenten.