Hola Al, creo que el concepto o palabrita que buscas es
Materializar, o
Materialize en inglés.
Este término se emplea en los frameworks de persistencia, y a mi ver Materializar no es propio de la persistencia en bases de datos, sino en su forma abstracta. Asi que no veo el porqué no aprovecharlo.
Ahora, respecto a la utilidad del código, si me lo permites quisiera preguntar algo ¿Donde o que clase "cliente" lo utilizará o invocará al método en cuestión? ¿O es que no existe un lugar concreto donde usarlo?
Como seguramente ya has visto un diseño de resultado booleano (objeto|nil) llevará a que al final se deba hacer una comprobación posterior, o bien hacer uso de try.
Ahora bien, si en verdad nil es un resultado realmente válido (tiene un significado real y está aceptado en el contexto) y no deja al objeto que cumple el rol del creador en un estado inconsistente no hay problemas. Pero si este nil en realidad no responde a un resultado aceptable y tolerable lo correcto sería que no se devolviese nil sino que se eleve una excepción. Como nombre podría sugerir EUnmaterializedException o ETXFileUnmaterializedException.
De este modo en donde se lo invoque simplemente se trabaja directamente con try y poder volver a un estado de calma sin estar alterando el flujo principal del código.
Por otro lado, Al... me huele a que estás diseñando una Fábrica.
Saludos,