Como quien implementa esta herramienta , startHttpServer
, debe intentar que sea la más sencilla, fluida y perfecta para usar ...
La lógica de la función
Técnicamente, al dividir la lógica de startHttpServer
en 2 funciones y llamándolas por separado , todo lo que haces es mover startHttpServer
's idempotency en el código que llama a ambas funciones en su lugar ... Además, a menos que incluya ambas lógicas en una tercera función ( que es lo que hace startHttpServer
en primer lugar), esto te obliga a escribir código no DRY, duplicándolo exponencialmente en cualquier lugar al que tengas que llamar startHttpServer
. En resumen, startHttpServer
debe llamarse a sí misma la función isHttpServerRunning
.
Así que mi punto es:
- Implemente la función
isHttpServerRunning
porque de todas formas esto puede ser necesario de forma independiente ...
- Implemente
startHttpServer
haciendo que use isHttpServerRunning
para definir su siguiente acción en consecuencia ...
Aún así, puede hacer que startHttpServer
devuelva cualquier valor que el usuario de esta función pueda necesitar, por ejemplo:
-
0
= > error de inicio del servidor
-
1
= > servidor de inicio exitoso
-
2
= > el servidor ya fue iniciado
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 iniciar algo que ya se ha iniciado, AKA 1*1=1
. Entonces, al menos para mí, llamarlo " ensureHttpServerIsRunning
" no parece ser una necesidad crítica, me preocuparía más sobre qué tan largo, natural y memorable es el nombre de la función.
Ahora, si desea saber cómo funciona en detalle la función bajo el capó, existe la fuente de la documentación o el código para eso, me refiero a cualquier otra función de library / framework / API / etc ...
Usted aprende la función una vez, mientras que la escribe varias veces ...
De todos modos, me quedaría con startHttpServer
que es más corto, más simple y más explícito que ensureHttpServerIsRunning
.