Termo (ou "padrão"?) Para "Faça algo se ainda não estiver pronto" [fechado]

Parece bastante básico, eu sei, mas recentemente um colega me disse que um método chamado startHttpServeré muito complicado de entender porque só inicia o servidor se ele ainda não estiver em execução. Percebo que tenho problemas quando respondo: "Sério? Faço isso há décadas - é um padrão comum na programação". Mais frequentemente do que gostaria de admitir, ele volta com algumas evidências documentadas que mostram que toda a comunidade de programação está por trás de seu ponto de vista e acabo me sentindo tímido.

Pergunta : Existe um padrão de design documentado por trás do conceito de um método que não é operacional se a ação necessária já estiver em vigor? Ou, se não for um padrão, também tem um nome? E se não, existe alguma razão para pensar que é muito complicado considerar escrever um método dessa maneira?

Como NickWilliams já disse : o conceito que o OP descreve é ​​chamado de idempotente (substantivo Idempotência ). É de fato uma prática comum, especialmente em APIs de alto nível.

MAS: Renomeie a função.

Em vez de startHttpServerchamá-lo makeSureHttpServerIsRunningou ensureHttpServerIsRunning.

Quando uma função é chamada startHttpServer, os leitores esperam que ela inicie um servidor HTTP; quando chamado dez vezes seguidas, terei dez servidores em execução. Sua função não faz isso na maioria das vezes. Além disso, o nome com "start" sugere que, se eu quiser apenas um servidor em execução, precisarei acompanhar se a função já foi chamada ou não.

Quando uma função é chamada makeSureHttpServerIsRunning, presumo que ela fará as coisas necessárias para garantir que um servidor HTTP esteja em execução, provavelmente verificando se já está em execução e iniciando-o de outra forma. Suponho também que a função verifique se o servidor está realmente em execução (iniciar um servidor pode envolver algum tempo em que ainda não está em execução).

Renomeie para EnsureServerRunning.

Completamente inequívoco e é claro que garante que esteja em execução (se não estiver) sem implicar uma reinicialização, se estiver.

(Alternativa StartServerIfNotRunning:?)

Não é realmente um padrão de design, mas eu chamaria seu método de idempotente . Geralmente, o termo é usado para se referir a chamadas remotas, mas a descrição parece corresponder ao que você está fazendo.

Métodos Idempotentes. Os métodos também podem ter a propriedade "idempotência", pois (além de problemas de erro ou expiração), os efeitos colaterais de N> 0 pedidos idênticos são os mesmos que para um único pedido. ( De W3.org )

O efeito colateral do servidor aqui é que o servidor http é iniciado assim que o método é chamado. Não vejo nada de errado em um método fazer isso.

Se você precisar de um padrão de design, acho que você pode expor seu httpServer como um singleton que é iniciado quando inicializado.

Como aquele que implementa essa ferramenta , startHttpServervocê deve tentar torná-la a mais simples, suave e perfeita de usar ...

A lógica da função

Tecnicamente, dividindo startHttpServera lógica em 2 funções e chamando-as separadamente , tudo o que você faz é mover startHttpServer a idempotência para o código chamando as duas funções ... Além disso, a menos que você envolva a lógica em uma terceira função (que é o que faz startHttpServerem primeiro lugar), isso obriga a escrever código não-SECADO, duplicando-o exponencialmente em qualquer lugar que você precise chamar startHttpServer. Em suma, startHttpServer tem que se chamar de isHttpServerRunningfunção.

Então, meu ponto é:

• Implemente a isHttpServerRunningfunção porque isso pode ser necessário independentemente, de qualquer maneira ...
• Implemente startHttpServero uso isHttpServerRunningpara definir sua próxima ação de acordo ...

Ainda assim, você pode startHttpServerretornar qualquer valor que o usuário dessa função possa precisar, por exemplo:

• 0 => falha na inicialização do servidor
• 1 => servidor iniciando com sucesso
• 2 => servidor já foi iniciado

A nomeação da função

Primeiro de tudo, qual é o objetivo principal do usuário? Para iniciar o servidor HTTP , certo?

Fundamentalmente, não há problema pretendendo iniciar algo que já foi iniciado, também conhecido como AKA 1*1=1. Então, pelo menos para mim, chamá-lo " ensureHttpServerIsRunning" não parece ser criticamente necessário, eu me importaria mais com quanto tempo, natural e memorável é o nome da função.

Agora, se você quiser saber como trabalhar em detalhes a função sob o capô, existe a documentação ou a fonte de código para isso, quero dizer, como para qualquer outra função da biblioteca / framework / API / etc ...

Você aprende a função uma vez enquanto a escreve várias vezes ...

Enfim, eu continuaria com o startHttpServerque é mais curto, mais simples e mais explícito do que ensureHttpServerIsRunning.

Suponho que seu colega quis dizer que startHttpServerestá fazendo muito:

• Verificando se o servidor já está em execução,
• Iniciando o servidor, se necessário.

Essas são duas partes não relacionadas do código. Por exemplo, existe uma situação semelhante quando um aplicativo de desktop deve garantir que ele ainda não esteja sendo executado quando iniciado; haverá uma parte do código que manipula instâncias de aplicativos (por exemplo, usando um mutex) e o código que iniciará o loop de mensagens do aplicativo.

Isso significa que você precisa ter não um, mas pelo menos dois métodos :

• isHttpServerRunning: boolean
• startHttpServer

O ponto de entrada do aplicativo chamará o primeiro método e, em seguida, o segundo se o valor de retorno for false. Agora, todo método está fazendo uma coisa e é fácil de entender.

^{¹ Se a lógica necessária para saber se o servidor já está em execução é muito complexa, pode ser necessária uma separação adicional em vários métodos.}

Como você não especifica um idioma, em JavaScript, muitas bibliotecas têm uma função "única", por exemplo, Sublinhado . Portanto, se isso lhe for familiar, chame-o de "uma vez" e renomeie seu método.

Eu mesmo, vindo mais do Java, os termos "armazenamento em cache" ou "avaliação lenta" vêm à mente. "Idempotente" é tecnicamente correto e uma boa escolha, esp. se você tiver um fundo mais funcional.

Eu preferiria startHttpServerIfNotIsRunning.

Dessa forma, a condição já está claramente mencionada no nome do método. Ensureou makeSureparece um pouco vago para mim, pois não é uma expressão técnica. Parece que não sabemos exatamente o que vai acontecer.

O que seu colega deveria ter lhe dito é que você não tem negócios escrevendo esse método. Já foi escrito muitas vezes e melhor do que você provavelmente escreverá. Por exemplo: http://docs.ansible.com/ansible/latest/systemd_module.html https://docs.saltstack.com/en/latest/ref/states/all/salt.states.service.html

De uma perspectiva arquitetônica, ter um pouco de código arbitrário gerenciando um servidor Web é coisa de pesadelo. A menos que gerenciar serviços seja exclusivamente o que seu código faz. Mas acho que você não escreveu monit (ou kubernetes ou ...).