Termine (o "modello"?) Per "Fai qualcosa se non è già stato fatto" [chiuso]

Sembra piuttosto semplice, lo so, ma recentemente ho avuto un collega che mi ha detto che un metodo chiamato startHttpServerè troppo complicato per capire perché avvia il server solo se non è già in esecuzione. Trovo di trovarmi nei guai quando rispondo, "Seriamente? Lo sto facendo da decenni - è un modello comune nella programmazione." Più spesso di quanto mi interessi ammettere che ritorna con alcune prove documentate che dimostrano che l'intera comunità di programmatori è dietro il suo punto di vista e finisco per sentirmi imbarazzato.

Domanda : esiste un modello progettuale documentato dietro il concetto di un metodo che non è operativo se l'azione richiesta è già in vigore? Oppure, se non uno schema, ha anche un nome? E se no, c'è qualche motivo per pensare che sia troppo complicato considerare di scrivere un metodo in questo modo?

Come NickWilliams ha già detto : il concetto descritto dall'OP si chiama idempotente (sostantivo Idempotency ). È davvero una pratica comune, specialmente nelle API di alto livello.

MA: Rinomina la funzione.

Invece di startHttpServerchiamarlo makeSureHttpServerIsRunningo ensureHttpServerIsRunning.

Quando viene chiamata una funzione startHttpServer, i lettori si aspettano che avvii un server HTTP; quando viene chiamato dieci volte di seguito, avrò dieci server in esecuzione. La tua funzione non lo fa per la maggior parte del tempo. Inoltre, il nome con "start" suggerisce che se voglio un solo server in esecuzione dovrò tenere traccia del fatto che la funzione sia già stata chiamata o meno.

Quando viene chiamata una funzione makeSureHttpServerIsRunning, suppongo che farà le cose necessarie per assicurarsi che un server HTTP sia in esecuzione, molto probabilmente controllando se è già in esecuzione e avviandolo altrimenti. Suppongo anche che la funzione assicuri che il server sia effettivamente in esecuzione (l'avvio di un server potrebbe richiedere del tempo in cui non è ancora in esecuzione).

Rinominalo in EnsureServerRunning.

Completamente inequivocabile ed è chiaro che si assicura che sia in esecuzione (se non lo è) senza implicare un riavvio se lo è.

(Alternativa StartServerIfNotRunning:?)

Non proprio un modello di progettazione, ma definirei il tuo metodo idempotente . Il termine viene generalmente utilizzato per fare riferimento a chiamate remote, ma la descrizione sembra corrispondere a ciò che si sta facendo.

Metodi idempotenti. I metodi possono anche avere la proprietà di "idempotenza" in quanto (a parte errori o problemi di scadenza) gli effetti collaterali di richieste identiche N> 0 sono le stesse di una singola richiesta. ( Da W3.org )

L'effetto collaterale del server è che il server http viene avviato una volta chiamato il metodo. Non vedo nulla di sbagliato in un metodo che fa questo.

Se hai bisogno di un modello di progettazione, suppongo che potresti esporre il tuo httpServer come un singleton che viene avviato quando inizializzato.

Come colui che implementa questo strumento , startHttpServerdovresti provare a renderlo il più semplice, fluido e senza soluzione di continuità da usare ...

La logica della funzione

Tecnicamente, dividendo startHttpServerla logica in 2 funzioni e chiamandole separatamente , tutto ciò che fai è spostare startHttpServer l' idempotenza nel codice chiamando entrambe le funzioni ... Inoltre, a meno che non avvolgi entrambe la logica in una terza funzione (che è ciò che fa startHttpServerin primo luogo), questo ti costringe a scrivere codice non DRY, duplicandolo esponenzialmente ovunque dovresti chiamare startHttpServer. In breve, startHttpServer deve chiamare se stessa la isHttpServerRunningfunzione.

Quindi il mio punto è:

• Implementare la isHttpServerRunningfunzione perché potrebbe essere necessario in modo indipendente comunque ...
• Implementalo startHttpServerfacendolo usare isHttpServerRunningper definire la sua prossima azione di conseguenza ...

Tuttavia, puoi startHttpServerrestituire qualsiasi valore di cui l'utente abbia bisogno in questa funzione, ad esempio:

• 0 => errore di avvio del server
• 1 => avvio server riuscito
• 2 => il server era già stato avviato

La denominazione della funzione

Prima di tutto, qual è l' obiettivo principale dell'utente? Per avviare il server HTTP , giusto?

Fondamentalmente, non c'è nessun problema con l'intenzione di iniziare qualcosa che è già stato avviato, AKA 1*1=1. Quindi, almeno per me, chiamarlo " ensureHttpServerIsRunning" non sembra assolutamente necessario, mi preoccuperei di più di quanto sia lungo, naturale e memorabile il nome della funzione.

Ora, se vuoi sapere come funziona in dettaglio la funzione sotto il cofano, c'è la documentazione o la fonte del codice per questo, intendo come per qualsiasi altra funzione da libreria / framework / API / ecc ...

Si impara la funzione di una volta, mentre si scrive che più volte ...

Quindi comunque, rimarrei con quello startHttpServerche è più breve, più semplice ed esplicito di ensureHttpServerIsRunning.

Suppongo che il tuo collega intendesse dire che startHttpServersta facendo troppo:

• Verifica se il server è già in esecuzione,
• Avvio del server, se necessario.

Quelle sono due parti non correlate del codice. Ad esempio, si verifica una situazione simile quando un'applicazione desktop dovrebbe assicurarsi che non sia già in esecuzione all'avvio; ci sarà una parte del codice che gestisce le istanze delle app (ad esempio usando un mutex) e il codice che avvierà il ciclo dei messaggi dell'applicazione.

Ciò significa che non devi avere uno, ma almeno¹ due metodi :

• isHttpServerRunning: boolean
• startHttpServer

Il punto di ingresso dell'applicazione chiamerà il primo metodo, quindi il secondo se il valore restituito è false. Ora, ogni metodo sta facendo una cosa sola ed è facile da capire.

^{¹ Se la logica necessaria per sapere se il server è già in esecuzione è troppo complessa, potrebbe essere necessaria un'ulteriore separazione in più metodi.}

Dal momento che non si specifica una lingua, in JavaScript molte librerie hanno una funzione "una volta", ad esempio Underscore . Quindi, se ti sarebbe familiare, chiamalo modello "una volta" e probabilmente rinomina il tuo metodo.

Io stesso, venendo più da Java, mi vengono in mente i termini "cache" o "valutazione pigra". "Idempotent" è tecnicamente corretto e una buona scelta, esp. se hai uno sfondo più funzionale.

Preferirei startHttpServerIfNotIsRunning.

In questo modo, la condizione è chiaramente menzionata già nel nome del metodo. Ensureo mi makeSuresembra un po 'vago, in quanto non è un'espressione tecnica. Sembra che non sappiamo esattamente cosa succederà.

Ciò che il tuo collega avrebbe dovuto dirti è che non hai affari a scrivere quel metodo. È già stato scritto molte volte e scritto meglio di quanto tu possa scriverlo. Ad esempio: http://docs.ansible.com/ansible/latest/systemd_module.html https://docs.saltstack.com/en/latest/ref/states/all/salt.states.service.html

Dal punto di vista architettonico, avere un po 'di codice arbitrario nella gestione di un web server è roba da incubi. A meno che la gestione dei servizi non sia esclusivamente ciò che fa il tuo codice. Ma suppongo che tu non abbia scritto monit (o kubernetes o ...).