A modificação de um parâmetro recebido é um antipadrão? [fechadas]

Estou programando em Java e sempre faço conversores assim:

public OtherObject MyObject2OtherObject(MyObject mo){
    ... Do the conversion
    return otherObject;
}

No novo local de trabalho, o padrão é:

public void MyObject2OtherObject(MyObject mo, OtherObject oo){
    ... Do the conversion
}

Para mim, é um pouco malcheiroso, pois me acostumei a não alterar os parâmetros recebidos. Essa alteração de parâmetro de entrada é um antipadrão ou está OK? Tem algumas desvantagens sérias?

Não é um antipadrão, é uma prática ruim.

A diferença entre um antipadrão e uma mera má prática está aqui: definição antipadrão .

O novo estilo de local de trabalho que você mostra é uma prática ruim , tempos vestigiais ou pré-POO, de acordo com o Código Limpo do tio Bob.

Os argumentos são naturalmente interpretados como entradas para uma função.

Tudo o que força você a verificar a assinatura da função é equivalente a uma olhada duas vezes. É uma quebra cognitiva e deve ser evitada. Nos dias anteriores à programação orientada a objetos, às vezes era necessário ter argumentos de saída. No entanto, grande parte da necessidade de argumentos de saída desaparece nas linguagens OO

Citando o famoso livro de Robert C. Martin "Clean Code":

Argumentos de saída devem ser evitados

As funções devem ter um pequeno número de argumentos

O segundo padrão viola as duas regras, particularmente o argumento "output output". Nesse sentido, é pior que o primeiro padrão.

O segundo idioma pode ser mais rápido, porque o chamador pode reutilizar uma variável em um loop longo, em vez de cada iteração criando uma nova instância.

Eu geralmente não usaria, mas por exemplo. na programação de jogos, ele tem seu lugar. Por exemplo, observe o lote de operações Vector3f do JavaMonkey permite passar a instância que deve ser modificada e retornada como resultado.

Eu não acho que essas são duas partes equivalentes de código. No primeiro caso, você deve criar o otherObject. Você pode modificar a instância existente no segundo. Ambos têm seus usos. O cheiro do código preferiria um ao outro.

Realmente depende do idioma.

Em Java, a segunda forma pode ser um antipadrão, mas algumas linguagens tratam a passagem de parâmetros de maneira diferente. Em Ada e VHDL por exemplo, em vez de passar por valor ou por referência, os parâmetros podem ter modos in, out, ou in out.

É um erro modificar um inparâmetro ou ler um outparâmetro, mas qualquer alteração em um in outparâmetro é passada de volta ao chamador.

Portanto, as duas formas no Ada (também são VHDL legais) são

function MyObject2OtherObject(mo : in MyObject) return OtherObject is
begin
    ... Do the conversion
    return otherObject;
end MyObject2OtherObject;

e

procedure MyObject2OtherObject(mo : in MyObject; oo : out OtherObject) is
begin
    ... Do the conversion
    oo := ... the conversion result;
end MyObject2OtherObject;

Ambos têm seus usos; um procedimento pode retornar vários valores em vários Outparâmetros enquanto uma função pode retornar apenas um único resultado. Como o objetivo do segundo parâmetro está claramente indicado na declaração do procedimento, não pode haver objeção a este formulário. Costumo preferir a função de legibilidade. mas haverá casos em que o procedimento é melhor, por exemplo, onde o chamador já criou o objeto.

Realmente parece mal cheiroso, e sem ver mais contexto é impossível dizer com certeza. Pode haver duas razões para fazer isso, embora existam alternativas para ambas.

Primeiro, é uma maneira concisa de implementar a conversão parcial ou deixar o resultado com valores padrão se a conversão falhar. Ou seja, você pode ter o seguinte:

public void ConvertFoo(Foo from, Foo to) {
    if (can't convert) {
        return;
    }
    ...
}

Foo a;
Foo b = DefaultFoo();
ConvertFoo(a, b);
// If conversion fails, b is unchanged

Obviamente, isso geralmente é tratado usando exceções. No entanto, mesmo que exceções precisem ser evitadas por qualquer motivo, existe uma maneira melhor de fazer isso - o padrão TryParse é uma opção.

Outro motivo é que pode ser por motivos de consistência pura, por exemplo, faz parte de uma API pública em que esse método é usado para todas as funções de conversão por qualquer motivo (como outras funções de conversão com várias saídas).

O Java não é bom em lidar com várias saídas - ele não pode ter parâmetros somente de saída, como algumas linguagens, ou ter vários valores de retorno como outros -, mas mesmo assim, você pode usar objetos de retorno.

A razão da consistência é um pouco ruim, mas, infelizmente, pode ser a mais comum.

• Talvez os policiais de estilo no seu local de trabalho (ou na sua base de código) venham de um background não Java e tenham relutado em mudar.
• Seu código pode ter sido uma porta de um idioma em que esse estilo é mais idiomático.
• Talvez sua organização precise manter a consistência da API em diferentes idiomas e esse foi o estilo de denominador comum mais baixo (é idiota, mas acontece até no Google ).
• Ou talvez o estilo tenha feito mais sentido no passado distante e tenha se transformado em sua forma atual (por exemplo, poderia ter sido o padrão TryParse, mas algum antecessor bem-intencionado removeu o valor de retorno depois de descobrir que ninguém o verificava).

A vantagem do segundo padrão é que ele força o chamador a assumir a propriedade e a responsabilidade pelo objeto criado. Não há dúvida de que o método criou ou não o objeto ou o obteve de um pool reutilizável. O chamador sabe que eles são responsáveis ​​pela vida útil e pelo descarte do novo objeto.

As desvantagens deste método são:

1. Não pode ser usado como um método de fábrica, o chamador deve conhecer o subtipo exato OtherObjectdele e construí-lo com antecedência.
2. Não pode ser usado com objetos que requerem parâmetros em seu construtor se esses parâmetros vierem MyObject. OtherObjectdeve ser construtível sem conhecer MyObject.

A resposta é baseada na minha experiência em c #, espero que a lógica se traduza em Java.

Dada a semântica solta - myObjectToOtherObjecttambém pode significar que você move alguns dados do primeiro objeto para o segundo ou que os converte inteiramente de novo, o segundo método parece mais adequado.

No entanto, se o nome do método fosse Convert(como deveria ser se olharmos para a parte "... faça a conversão"), eu diria que o segundo método não faria sentido. Você não converte um valor em outro valor que já exista, IMO.