Estoy creando un objeto cuyo único propósito es leer en un archivo de un formato y crear otro de un formato diferente.
¿Es mejor crear el archivo de salida implícitamente durante la inicialización del objeto o tener un método público que le dé al usuario la opción de cuándo se creará este archivo?
Respuestas:
Si está trabajando en un idioma que lo admite, le proporcionaría un método Save que toma un Stream. De esa manera, el usuario puede guardar los datos donde quiera.
Se tarda 20 segundos más en escribir que guardar solo en un archivo, pero un programador lo comprende fácilmente, y en el sitio de llamada queda muy claro lo que realmente sucede.
La forma en que lo describió (un objeto que lee entradas y salidas a otro archivo) parece extraño. ¿Cuál es el propósito de construir un objeto que hace todo durante la construcción?
¿Lo llamarías así?
var stuff = DoStuff();
new SaveFileWeirdClass(stuff);
return;
Para cualquier implementación razonable de SaveFileWeirdClass, no esperaría ningún efecto secundario con solo crearlo. Leyendo un archivo - bien. ¿Crear un archivo? No.
A mí me parece más claro de esta manera:
var stuff = new StuffReader(); //Better name needed...
string filePath = this.whatever;
using(Stream stream = new FileStream(filePath))
stuff.Save(stream);
Si está decidido a hacerlo en la clase, créelo durante la inicialización. Retrasar ese paso hace dos cosas malas: Primero, agrega un paso adicional y explícito para la persona que llama, que no habría creado el objeto en primer lugar a menos que tuvieran la intención de usarlo para producir resultados. En segundo lugar, agrega al menos dos puntos en los que el código de la clase tiene que tomar una decisión sobre si el archivo está abierto o no y manejar esa condición: una vez cuando va a escribir la salida y una vez durante la destrucción cuando va a cerrarlo. Lo primero significa que tienes que hacer esa verificación durante cada escritura, lo que podría ser un desperdicio si haces muchas de ellas.
Personalmente, no haría ninguna de las dos opciones y optaría por hacer que la persona que llama transfiera los identificadores de archivos previamente abiertos al constructor. Crear el archivo dentro de la clase impide dar a las personas que llaman las opciones para hacer cosas como establecer permisos o, si escribe en un dispositivo, realizar una inicialización específica del dispositivo. Si desea tener una versión de su FooConverterclase que opere en archivos y haga el trabajo de creación, envuélvala en un FooFileConverter.
Explícitamente.
Desea asegurarse de no confiar en reglas inteligentes de efectos secundarios que pueden romperse en futuras versiones o en arquitecturas poco comunes. Por supuesto, debe tener un archivo predeterminado que el usuario pueda sobrescribir si así lo desea.
Además de los otros argumentos para un método explícito: si hace el trabajo en el constructor, obliga a todos los usuarios de su clase a hacer un manejo de excepciones solo para crear el objeto. Esto puede conducir a un montón de código repetitivo.
Ver /programming/6086334/is-it-good-practice-to-make-the-constructor-throw-an-exception para una discusión sobre eso.