É um cheiro de código chamar método público em método privado da mesma instância de objeto?
É um cheiro de código chamar método público em método privado da mesma instância de objeto?
Respostas:
Não, não cheiro ruim. Isso pode ser necessário, por que você suspeita que esteja errado? Um método no nível atômico é uma entidade independente que executa uma tarefa. Desde que execute uma tarefa, qualquer pessoa que tenha acesso a ela poderá chamá-la para concluir a tarefa.
Código cheiro? Sim, não é realmente ruim, mas é um bom indicador de que a classe pode ter muitas responsabilidades.
Tome isso como um sinal de que a classe pode precisar ser dividida em diferentes objetos; os métodos privados não precisam realmente chamar métodos públicos do mesmo objeto, certamente em um design limpo de OO.
Obviamente, depois de inspecionar a classe e os motivos da chamada do método ficarem claros, pode ser um uso perfeitamente razoável; em geral, você espera que os métodos utilitários da classe sejam privados, mas se um for útil o suficiente para ser público e utilizado por outros métodos, eu geralmente esperaria que esses métodos também fossem públicos.
Como em todos os odores de código, isso é uma motivação para uma inspeção mais aprofundada, racionalizar e talvez refatorar, mas não é motivo de alarme.
Pode levar a surpresas desagradáveis se alguém que não leu o código fonte dessa classe tentar subclassificá-lo e substituir o método público. Se essa é uma preocupação real, obviamente depende da sua situação. Talvez você deva considerar tornar o método público ou até a aula final.
Não. O que mais deve ser feito nesse caso? Tornar público o método privado ou privado? Copiar e colar o código do método público para o privado?
NÃO , não tem cheiro ruim aqui.
se implementarmos a interface de uma fila com a List, é um mau cheiro chamar apenas as funções de List apropriadas para conseguir a implementação da fila facilmente?
se você tem alguma coisa e deseja convertê-la em outra coisa (como wrapper), então não é um mau cheiro, seu código pode ser reutilizado com padrão de design atuado no nível da função (a função é um objeto?)
Sei que este é um post antigo, mas é algo que venho debatendo no trabalho. Considero isso um cheiro de código e não consigo entender por que você gostaria de fazer isso. Se um método privado precisar chamar um método público, o conteúdo do método público deverá ser utilizado e colocado em um método privado, que os dois métodos poderão chamar. Por quê?
O método público pode conter testes que não são necessários após a execução interna do código. Ele pode receber um UserObj e deseja testar permissões de usuário, por exemplo.
Após uma chamada pública, você pode ter um requisito para bloquear o objeto, se estiver usando a segmentação, então internamente, você não gostaria de chamar de volta para um método público.
É mais provável que eu introduza erros circulares, loops infinitos e exceções de mem na minha opinião.
Simples e simples, design ruim e "preguiçoso". Métodos públicos fornecem acesso ao mundo exterior. Não há razão para voltar para fora quando você já está dentro.
Imagine o contrário. Você está em um método privado e precisa da funcionalidade em um método público. E se você não pudesse chamar esse método público pelo privado. O que você faria?
A resposta é clara: quando você quiser a funcionalidade em um método público, poderá chamá-lo a partir de métodos dessa classe ou de outras classes.
No meu código, geralmente crio getters de carregamento lento, ou seja, o objeto é inicializado na primeira vez em que é solicitado e depois reutiliza o mesmo objeto instanciado. No entanto, um objeto instanciado usando uma carga lenta implica que ele não pode necessariamente ser instanciado em um determinado momento. Em vez de entender a sequência de chamadas de modo que eu saiba que esse objeto já está instanciado ou repita o mesmo código de uma carga lenta dentro de outro método, eu simplesmente chamo o carregador lento sempre que preciso desse objeto.
Assim como você pode usar métodos públicos de maneira inteligente, também pode usá-los incorretamente. Um exemplo disso pode ser um método público que processa seus parâmetros antes de chamar outro método privado. Seria um erro chamar esse método público casualmente simplesmente porque você tem os mesmos parâmetros. O erro é sutil, mas é um erro de design mais do que qualquer outra coisa e requer que você aprenda a gerenciar com os parâmetros do método interno e não com os parâmetros do método público.
Portanto, para responder sua pergunta, certamente não é um código ruim se você o usar corretamente.
A pergunta que você precisa fazer é: por que sua turma tem a mesma necessidade dos clientes da sua turma? Normalmente, uma classe tem necessidades muito diferentes de seus clientes. Então, sim, isso é uma indicação de que você tem
(a) expôs algo publicamente que deveria ser privado; ou
(b) o comportamento da classe não é restrito o suficiente (pense no princípio da responsabilidade única).