Prefere membros da classe ou passando argumentos entre métodos internos?

Question

Prefere membros da classe ou passando argumentos entre métodos internos?

#1 resposta do (14 votos)
#2 resposta do (12 votos)
#3 resposta do (7 votos)
#4 resposta do (1 votos)
#5 resposta do (1 votos)
#6 resposta do (0 votos)

37

Suponha que dentro da parte privada de uma classe exista um valor que é utilizado por múltiplos métodos privados. As pessoas preferem ter isso definido como uma variável de membro para a classe ou passando-a como um argumento para cada um dos métodos - e por quê?

Por um lado eu poderia ver um argumento a ser feito que reduzir estado (ie variáveis de membro) em uma classe geralmente é uma coisa boa, embora se o mesmo valor está sendo repetidamente usado em métodos de uma classe, parece que ser um candidato ideal para a representação como estado da classe para tornar o código visivelmente mais limpo, se nada mais.

Editar:

Para esclarecer alguns dos comentários / questões que foram levantadas, não estou falando de constantes e isso não está relacionado a nenhum caso em particular, mas apenas a uma hipotética sobre a qual eu estava conversando com outras pessoas.

Ignorando o ângulo OOP por um momento, o caso de uso específico que eu tinha em mente era o seguinte (suponha passar por referência apenas para tornar o limpador de pseudocódigo)

int x
doSomething(x)
doAnotherThing(x)
doYetAnotherThing(x)
doSomethingElse(x)

Então, o que quero dizer é que há alguma variável que é comum entre múltiplas funções - no caso que eu tinha em mente, era devido ao encadeamento de funções menores. Em um sistema OOP, se fossem todos os métodos de uma classe (digamos, devido à refatoração por meio da extração de métodos de um método grande), essa variável poderia ser passada em torno de todos ou poderia ser um membro da classe.

code-quality java variables methods class-design

por geoffjentry 27.09.2011 / 23:27

fonte

6 respostas

Tags code-quality java variables methods class-design

Como organizar programas funcionais [duplicados] Evidência Empírica de Popularidade de Git e Mercurial

score 14 · Answer 1

Se o valor for uma propriedade da classe, mantenha-o na classe, caso contrário, mantenha-o fora. Você não projeta seus métodos de classe - primeiro, você projeta suas propriedades primeiro. Se você não pensou em colocar essa propriedade dentro da classe, provavelmente há uma razão para isso.

A pior coisa que você pode fazer, em termos de escalabilidade, é alterar seu código por conveniência. Mais cedo ou mais tarde, você verá que seu código está inchado e duplicado. No entanto, devo admitir que às vezes eu quebro essa regra ... A conveniência é tão atraente.

score 12 · Answer 2

Se você realmente não precisa manter o estado entre invocações (e aparentemente você não faz, ou você não faria a pergunta) então eu preferiria que o valor fosse um argumento, ao invés de uma variável membro, porque uma rápida olhada na assinatura do método diz que ele usa o argumento, enquanto é um pouco mais difícil dizer imediatamente quais variáveis de membro são usadas pelo método. Também nem sempre é rápido determinar quais variáveis de membros privados são.

Então, normalmente eu não concordaria que o código usando variáveis de membro é visivelmente mais limpo, mas se as assinaturas do método estão ficando fora de controle, eu posso fazer uma exceção. É uma pergunta que vale a pena, mas não é algo que o projeto vai depender em qualquer caso.

score 7 · Answer 3

Obrigado por fazer a pergunta, eu queria perguntar isso também.

Quando eu estava pensando sobre isso, há algumas vantagens em por que passá-lo como argumento

é mais fácil de testar - > mais fácil de manter (relacionado ao último ponto)
não tem efeitos colaterais
é mais fácil entender

Eu vejo claramente o seu ponto por exemplo - um está analisando o documento do Excel (usando a biblioteca POI por exemplo) e, em vez de passar a instância de linha para cada método que precisa trabalhar com essa linha, o autor tem a variável de membro currentRow e trabalha com isso.

Eu diria que deveria haver um nome para esse antipadrão, é? (não listado aqui )

score 1 · Answer 4

Talvez você deva extrair uma nova classe contendo todos os métodos que compartilham esse valor. Claro que o método de nível mais alto será público na nova classe. Pode ser útil expor esse método para testes.

Se você tem dois ou mais temporários que são sempre passados juntos, então você provavelmente deve extrair uma nova classe.

score 1 · Answer 5

Do people prefer having this defined as a member variable for the class or passing it as an argument to each of the methods - and why?

Se eu entendi o que você está perguntando: Os métodos em uma classe são, por definição, parecidos com os detalhes da implementação, então eu não tenho nenhum escrúpulo em usar qualquer membro diretamente de qualquer método.

On one hand I could see an argument to be made that reducing state (ie member variables) in a class is generally a good thing...

Não há nada errado em declarar um private static final para definir constantes. O compilador poderá usar o valor considerando algumas otimizações e, sendo constantes, elas não adicionam realmente o estado à classe.

although if the same value is being repeatedly used throughout a class' methods...

Ser capaz de se referir a ele simbolicamente (por exemplo, BLRFL_DURATION ) e não precisar adicionar argumentos extras a seus métodos tornará seu código mais legível e, portanto, mais sustentável.

score 0 · Answer 6

se o valor não mudar, é por definição uma constante e deve ser encapsulado dentro da classe. Nesse caso, não é considerado afetar o estado de um objeto. Eu não sei o seu caso, mas penso em algo como o PI na trigonometria. Se você tentar passar um argumento de tal constante, você poderia expor o resultado ao erro se o cliente passar o valor errado ou um valor não com a mesma precisão que o (s) método (s) espera (s).