Término (¿o "patrón"?) Para "Hacer algo si aún no está hecho" [cerrado]

Suena bastante básico, lo sé, pero recientemente tuve un colega que me dijo que un método llamado startHttpServeres demasiado complicado de entender porque solo inicia el servidor si aún no se está ejecutando. Encuentro que me meto en problemas cuando respondo: "¿En serio? He estado haciendo esto durante décadas, es un patrón común en la programación". Más a menudo de lo que me importa admitir que regresa con alguna evidencia documentada que muestra que toda la comunidad de programación está detrás de su punto de vista y termino sintiéndome avergonzado.

Pregunta : ¿Existe un patrón de diseño documentado detrás del concepto de un método que no funciona si la acción requerida ya está vigente? O, si no es un patrón, ¿tiene un nombre? Y si no, ¿hay alguna razón para pensar que es demasiado complicado considerar escribir un método de esta manera?

Como NickWilliams ya ha dicho : el concepto que describe el OP se llama idempotente (sustantivo Idempotency ). De hecho, es una práctica común, especialmente en las API de alto nivel.

PERO: Cambiar el nombre de la función.

En lugar de startHttpServerllamarlo makeSureHttpServerIsRunningo ensureHttpServerIsRunning.

Cuando se llama a una función startHttpServer, los lectores esperan que inicie un servidor HTTP; cuando me llamen diez veces seguidas, tendré diez servidores ejecutándose. Su función no hace eso la mayor parte del tiempo. Además, el nombre con "inicio" sugiere que si quiero que solo se ejecute un servidor, tendré que hacer un seguimiento de si la función ya se ha llamado o no.

Cuando se llama a una función makeSureHttpServerIsRunning, supongo que hará lo necesario para asegurarse de que se está ejecutando un servidor HTTP, lo más probable es que verifique si ya se está ejecutando y lo inicie de otra manera. También supongo que la función se asegura de que el servidor se esté ejecutando realmente (iniciar un servidor puede implicar un tiempo en el que aún no se está ejecutando).

Renombrarlo a EnsureServerRunning.

Completamente inequívoco y está claro que se asegura de que se esté ejecutando (si no lo está) sin implicar un reinicio si lo está.

(Alternativa StartServerIfNotRunning:?)

No es realmente un patrón de diseño, pero llamaría idemotente a su método . Su término generalmente se usa para referirse a llamadas remotas, pero la descripción parece coincidir con lo que está haciendo.

Métodos idempotentes. Los métodos también pueden tener la propiedad de "idempotencia" en que (aparte de los problemas de error o caducidad) los efectos secundarios de N> 0 solicitudes idénticas son las mismas que para una solicitud única. ( De W3.org )

El efecto secundario del servidor aquí es que el servidor http se inicia una vez que se llama al método. No veo nada de malo con un método que haga esto.

Si necesita un patrón de diseño, supongo que podría exponer su httpServer como un singleton que se inicia cuando se inicializa.

Como el que implementar esta herramienta , startHttpServer, usted debe estar tratando de hacer que sea lo más simple, suave y sin costuras para uso ...

La lógica de la función

Técnicamente, al dividir startHttpServerla lógica en 2 funciones y llamarlas por separado , todo lo que haces es mover startHttpServer la idempotencia al código que llama a ambas funciones en su lugar ... Además, a menos que envuelva ambas lógicas en una tercera función (que es lo que hace startHttpServeren primer lugar), esto te obliga a escribir código sin DRY, duplicándolo exponencialmente en todas partes a las que deberías llamar startHttpServer. En resumen, startHttpServer tiene que llamarse a sí mismo la isHttpServerRunningfunción.

Entonces mi punto es:

• Implemente la isHttpServerRunningfunción porque esto puede ser necesario independientemente de todos modos ...
• Implemente startHttpServerhacer que se use isHttpServerRunningpara definir su próxima acción en consecuencia ...

Aún así, puede startHttpServerdevolver cualquier valor que el usuario de esta función pueda necesitar, por ejemplo:

• 0 => falla de inicio del servidor
• 1 => servidor iniciando con éxito
• 2 => el servidor ya se inició

El nombre de la función.

En primer lugar, ¿cuál es el objetivo principal del usuario? Para iniciar el servidor HTTP , ¿verdad?

Fundamentalmente, no hay ningún problema al intentar comenzar algo que ya se ha iniciado, también conocido como AKA 1*1=1. Entonces, al menos para mí, llamarlo " ensureHttpServerIsRunning" parece no ser críticamente necesario, me importaría más cuánto tiempo, natural y memorable sea el nombre de la función.

Ahora, si desea saber cómo funciona en detalle la función bajo el capó, existe la documentación o el código fuente para eso, me refiero a cualquier otra función de biblioteca / marco / API / etc ...

Usted aprenderá la función de una vez mientras que escribir varias veces ...

De todos modos, me quedaría con lo startHttpServerque es más corto, más simple y más explícito que ensureHttpServerIsRunning.

Supongo que su colega quería decir que startHttpServerestá haciendo demasiado:

• Comprobando si el servidor ya se está ejecutando,
• Iniciando el servidor si es necesario.

Esas son dos partes de código no relacionadas. Por ejemplo, existe una situación similar cuando una aplicación de escritorio debe asegurarse de que no se esté ejecutando cuando se inicia; habrá una parte del código que maneja las instancias de la aplicación (por ejemplo, usando un mutex), y el código que iniciará el bucle de mensajes de la aplicación.

Esto significa que debe tener no uno, sino al menos dos métodos :

• isHttpServerRunning: boolean
• startHttpServer

El punto de entrada de la aplicación llamará al primer método, y luego al segundo si el valor de retorno es false. Ahora, cada método está haciendo una cosa y es fácil de entender.

^{¹ Si la lógica necesaria para saber si el servidor ya se está ejecutando es demasiado compleja, puede requerir una separación adicional en varios métodos.}

Como no especifica un idioma, en JavaScript muchas bibliotecas tienen una función de "una vez", por ejemplo, subrayado . Entonces, si eso le resulta familiar, llámelo "una vez" y posiblemente cambie el nombre de su método.

Yo mismo, viniendo más de Java, me vienen a la mente los términos "almacenamiento en caché" o "evaluación perezosa". "Idempotente" es técnicamente correcto y una buena opción, especialmente. si tienes un fondo más funcional.

Yo prefiero startHttpServerIfNotIsRunning.

De esta manera, la condición ya se menciona claramente en el nombre del método. Ensureo me makeSureparece un poco vago, ya que no es una expresión técnica. Parece que no sabemos exactamente qué va a pasar.

Lo que su colega debería haberle dicho es que no tiene por qué escribir ese método. Ya se ha escrito muchas veces, y se ha escrito mejor de lo que es probable que lo escriba. Por ejemplo: http://docs.ansible.com/ansible/latest/systemd_module.html https://docs.saltstack.com/en/latest/ref/states/all/salt.states.service.html

Desde una perspectiva arquitectónica, tener un poco de código arbitrario para administrar un servidor web es cosa de pesadillas. A menos que administrar servicios sea exclusivamente lo que hace su código. Pero supongo que no escribiste monit (o kubernetes o ...).