Estou criando um objeto cujo único objetivo é ler em um arquivo de um formato e criar outro de um formato diferente.
É melhor criar o arquivo de saída implicitamente durante a inicialização do objeto ou ter um método público que permita ao usuário escolher quando esse arquivo será criado?
Respostas:
Se você estiver trabalhando em um idioma que o suporte, eu forneceria um método Save que usa um Stream. Dessa forma, o usuário pode salvar os dados onde quiser.
Demora 20 segundos a mais para gravar do que salvar apenas em um arquivo, mas é facilmente compreendido por um programador e, no site de chamada, é muito claro o que realmente acontece.
A maneira como você o descreveu (um objeto que lê entrada e sai para outro arquivo) parece estranho. Qual é o propósito de construir um objeto que faz tudo durante a construção?
Você chamaria assim?
var stuff = DoStuff();
new SaveFileWeirdClass(stuff);
return;
Para qualquer implementação razoável de SaveFileWeirdClass, eu não esperaria efeitos colaterais apenas da criação. Lendo um arquivo - tudo bem. Criando um arquivo? Não.
Para mim, parece mais claro assim:
var stuff = new StuffReader(); //Better name needed...
string filePath = this.whatever;
using(Stream stream = new FileStream(filePath))
stuff.Save(stream);
Se você está disposto a fazê-lo na classe, crie-o durante a inicialização. Atrasar essa etapa faz duas coisas ruins: primeiro, ela adiciona uma etapa explícita extra ao chamador, que não teria criado o objeto em primeiro lugar, a menos que pretendessem usá-lo para produzir saída. Segundo, ele adiciona pelo menos dois pontos em que o código da classe precisa tomar uma decisão sobre se o arquivo está aberto ou não e lidar com essa condição: uma vez quando você escreve a saída e uma vez durante a destruição quando a fecha. O primeiro significa que você deve fazer essa verificação a cada gravação, o que pode ser um desperdício se você estiver fazendo muitas delas.
Pessoalmente, eu não faria nada e optaria por fazer o chamador transmitir identificadores de arquivo pré-abertos ao construtor. A criação do arquivo dentro da classe impede que os chamadores tenham opções para definir permissões ou, se estiver gravando em um dispositivo, fazer a inicialização específica do dispositivo. Se você deseja ter uma versão da sua FooConverterclasse que opere em arquivos e que o grunhido da criação funcione, envolva-a em FooFileConverter.
Explicitamente.
Você quer ter certeza de não confiar em regras inteligentes de efeito colateral que possam quebrar em versões futuras ou em arquiteturas incomuns. Obviamente, você deve ter um arquivo padrão que o usuário possa sobrescrever caso deseje.
Além dos outros argumentos para um método explícito: Se você faz o trabalho no construtor, força todos os usuários da sua classe a manipular exceções apenas para criar o objeto. Isso pode levar a muito código clichê.
Consulte /programming/6086334/is-it-good-practice-to-make-the-constructor-throw-an-exception para obter uma discussão sobre isso.