Os métodos init () têm cheiro de código?

Existe algum propósito para declarar um init()método para um tipo?

Não estou perguntando se devemos preferir init()a um construtor ou como evitar a declaraçãoinit() .

Estou perguntando se existe alguma justificativa por trás da declaração de um init()método (ver quão comum é) ou se é um cheiro de código e deve ser evitado.

O init()idioma é bastante comum, mas ainda não vi nenhum benefício real.

Estou falando de tipos que incentivam a inicialização por meio de um método:

class Demo {
    public void init() {
        //...
    }
}

Quando isso será útil no código de produção?

Eu sinto que pode ser um cheiro de código, pois sugere que o construtor não inicializa totalmente o objeto, resultando em um objeto parcialmente criado. O objeto não deve existir se seu estado não estiver definido.

Isso me faz acreditar que pode fazer parte de algum tipo de técnica usada para acelerar a produção, no sentido de aplicativos corporativos. É a única razão lógica pela qual consigo pensar em ter esse idioma. Só não tenho certeza de como isso seria benéfico.

Sim, é um cheiro de código. Um cheiro de código não é algo que necessariamente sempre precise ser removido. É algo que faz você dar uma segunda olhada.

Aqui você tem um objeto em dois estados fundamentalmente diferentes: pré-inicialização e pós-inicialização. Esses estados têm responsabilidades diferentes, métodos diferentes que podem ser chamados e comportamento diferente. São efetivamente duas classes diferentes.

Se você criar fisicamente duas classes separadas, removerá estaticamente toda uma classe de possíveis bugs, ao custo de talvez fazer com que seu modelo não corresponda tanto ao "modelo do mundo real". Você costuma nomear o primeiro Configou Setupou algo parecido.

Portanto, da próxima vez, tente refatorar seus idiomas de construção-init em modelos de duas classes e veja como isso acontece para você.

Depende.

Um initmétodo é um cheiro de código quando não é necessário separar a inicialização do objeto do construtor. Às vezes, há casos em que faz sentido separar essas etapas.

Uma rápida pesquisa no Google me deu esse exemplo. Posso facilmente imaginar mais casos em que o código executado durante a alocação de objetos (o construtor) pode ser melhor separado da própria inicialização. Talvez você tenha um sistema nivelado e a alocação / construção ocorra no nível X, mas a inicialização apenas no nível Y, porque apenas Y pode fornecer os parâmetros necessários. Talvez o "init" seja caro e precise ser executado apenas para um subconjunto dos objetos alocados, e a determinação desse subconjunto só pode ser feita no nível Y. Ou você deseja substituir o método "init" (virtual) em um derivado classe que não pode ser feita com um construtor. Talvez o nível X forneça objetos alocados de uma árvore de herança, mas o nível Y não tenha conhecimento da derivação concreta, apenas sobre a interface comum (ondeinit talvez definido).

Obviamente, para minha experiência, esses casos são apenas uma pequena porcentagem do caso padrão, onde toda inicialização pode ser feita diretamente no construtor e, sempre que você initvir um método separado , pode ser uma boa idéia questionar sua necessidade.

Minha experiência se divide em dois grupos:

1. Código em que init () é realmente necessário. Isso pode ocorrer quando uma superclasse ou estrutura impede o construtor de sua classe de obter todas as suas dependências durante a construção.
2. Código em que init () é usado, mas poderia ter sido evitado.

Na minha experiência pessoal, vi apenas algumas instâncias de (1), mas muitas outras instâncias de (2). Consequentemente, eu normalmente assumo que init () é um cheiro de código, mas nem sempre é esse o caso. Às vezes você simplesmente não consegue contornar isso.

Descobri que o uso do Padrão do Construtor geralmente pode ajudar a remover a necessidade / desejo de ter um init ().

Um cenário típico quando um método Init é útil é quando você tem um arquivo de configuração que deseja alterar e que a alteração seja levada em consideração sem reiniciar o aplicativo. Obviamente, isso não significa que um método Init deva ser chamado separadamente de um construtor. Você pode chamar um método Init de um construtor e depois mais tarde quando / se os parâmetros de configuração mudarem.

Resumindo: quanto à maioria dos dilemas existentes, seja um cheiro de código ou não, depende da situação e das circunstâncias.

Depende de como você os usa.

Eu uso esse padrão em linguagens de coleta de lixo como Java / C # quando não quero realocar um objeto na pilha (como quando estou criando um videogame e preciso manter o desempenho alto, os coletores de lixo diminuem o desempenho). Eu uso o construtor para fazer outras alocações de heap necessárias e initcriar o estado útil básico antes de cada vez que eu quiser reutilizá-lo. Isso está relacionado ao conceito de conjuntos de objetos.

Também é útil se você tiver vários construtores que compartilhem um subconjunto comum de instruções de inicialização, mas nesse caso initserão privados. Dessa forma, posso minimizar cada construtor o máximo possível, para que cada um contenha apenas instruções exclusivas e uma única chamada initpara fazer o resto.

Em geral, porém, é um cheiro de código.

init()Os métodos podem fazer bastante sentido quando você possui objetos que precisam de recursos externos (como, por exemplo, uma conexão de rede) que são usados ​​simultaneamente por outros objetos. Você pode não querer / precisar monopolizar o recurso durante a vida útil do objeto. Nessas situações, talvez você não queira alocar o recurso no construtor quando a alocação de recursos provavelmente falhar.

Especialmente na programação incorporada, você deseja ter uma pegada de memória determinística, por isso é uma prática comum (boa?) Chamar seus construtores mais cedo, talvez até estáticos, e somente inicializar mais tarde quando certas condições forem atendidas.

Fora desses casos, acho que tudo deve entrar em um construtor.

Geralmente, prefiro um construtor que recebe todos os argumentos necessários para uma instância funcional. Isso deixa claro todas as dependências desse objeto.

Por outro lado, uso uma estrutura de configuração simples que requer um construtor público sem parâmetros e interfaces para injetar dependências e valores de configuração. Depois disso, a estrutura de configuração chama o initmétodo do objeto: agora você recebeu tudo o que tenho para você, execute as últimas etapas para se preparar para o trabalho. Mas observe: é a estrutura de configuração que chama automaticamente o método init, para que você não esqueça de chamá-lo.

Não há cheiro de código se o método init () - é semanticamente incorporado no ciclo de vida do objeto.

Se você precisar chamar init () para colocar o objeto em um estado consistente, é um cheiro de código.

Existem várias razões técnicas para que essa estrutura exista:

1. gancho de estrutura
2. redefinindo o objeto para o estado inicial (evite redundância)
3. possibilidade de substituir durante os testes

O nome init às vezes pode ser opaco. Vamos pegar um carro e um motor. Para dar partida no carro (apenas ligar, ouvir rádio), você deseja verificar se todos os sistemas estão prontos para o uso.

Então você constrói um motor, uma porta, uma roda, etc. sua tela mostra motor = desligado.

Não há necessidade de começar a monitorar o motor etc., pois todos são caros. Então, quando você liga a chave para ligar, ligue para engine-> start. Começa a executar todos os processos caros.

Agora você vê engine = on. E o processo de ignição começa.

O carro não liga sem o motor disponível.

Você pode substituir o mecanismo pelo seu cálculo complexo. Como uma célula do Excel. Nem todas as células precisam estar ativas com todos os manipuladores de eventos o tempo todo. Quando você se concentra em uma célula, pode iniciá-la. Aumentando o desempenho dessa maneira.