Termin (czy „wzór”?) Dla „Zrób coś, jeśli jeszcze tego nie zrobiono” [zamknięte]

Brzmi dość prosto, wiem, ale ostatnio mój kolega powiedział mi, że wywoływana metoda startHttpServerjest zbyt skomplikowana, aby ją zrozumieć, ponieważ uruchamia serwer tylko wtedy, gdy jeszcze nie działa. Czuję, że wpadam w kłopoty, kiedy odpowiadam: „Poważnie? Robiłem to od dziesięcioleci - to powszechny schemat programowania”. Częściej niż chciałbym przyznać, że powraca z udokumentowanymi dowodami, które pokazują, że cała społeczność programistów stoi za jego punktem widzenia i ostatecznie czuję się zakłopotana.

Pytanie : Czy istnieje udokumentowany wzorzec projektowy za koncepcją metody, która nie działa, jeśli wymagane działanie jest już skuteczne? A może, jeśli nie jest wzorem, ma też nazwę? A jeśli nie, to czy jest jakiś powód, by sądzić, że zbyt skomplikowane jest rozważenie napisania metody w ten sposób?

Jak już powiedział NickWilliams : koncepcja OP opisana jest jako idempotent (rzeczownik Idempotency ). Jest to rzeczywiście powszechna praktyka, szczególnie w interfejsach API wysokiego poziomu.

ALE: Zmień nazwę funkcji.

Zamiast startHttpServernazywać to makeSureHttpServerIsRunninglub ensureHttpServerIsRunning.

Po wywołaniu funkcji startHttpServerczytelnicy oczekują, że uruchomi serwer HTTP; kiedy zostanie wywołany dziesięć razy z rzędu, będę miał dziesięć serwerów działających. Twoja funkcja nie robi tego przez większość czasu. Dodatkowo nazwa z „start” sugeruje, że jeśli chcę, aby działał tylko jeden serwer, muszę śledzić, czy funkcja została już wywołana, czy nie.

Kiedy funkcja jest wywoływana makeSureHttpServerIsRunning, zakładam, że wykona niezbędne czynności, aby upewnić się, że serwer HTTP działa, najprawdopodobniej sprawdzając, czy już działa, i uruchamiając go w inny sposób. Zakładam również, że funkcja zapewnia, że ​​serwer faktycznie działa (uruchomienie serwera może zająć trochę czasu, gdy jeszcze nie działa).

Zmień nazwę na EnsureServerRunning.

Całkowicie jednoznaczne i jasne, że zapewnia, że ​​działa (jeśli nie jest), bez sugerowania ponownego uruchomienia, jeśli tak jest.

(Alternatywnie StartServerIfNotRunning:?)

Nie jest to wzorzec projektowy, ale nazwałbym tę metodę idempotentną . Termin ten jest zwykle używany w odniesieniu do połączeń zdalnych, ale opis wydaje się pasować do tego, co robisz.

Idempotentne metody. Metody mogą również mieć właściwość „idempotence”, ponieważ (oprócz błędów związanych z błędem lub wygasaniem) skutki uboczne N> 0 identycznych żądań są takie same jak w przypadku pojedynczego żądania. ( Z W3.org )

Efektem ubocznym serwera jest tutaj to, że serwer HTTP jest uruchamiany po wywołaniu metody. Nie widzę nic złego w tej metodzie.

Jeśli potrzebujesz wzorca projektowego, myślę, że możesz udostępnić swój serwer HTTP jako singleton, który jest uruchamiany po zainicjowaniu.

Jako ten, który wdraża to narzędzie , startHttpServerpowinieneś starać się, aby było to najprostsze, płynne i bezproblemowe w użyciu ...

Logika funkcji

Technicznie rzecz biorąc, przez rozszczepienie startHttpServerjest logika w 2 funkcje i nazywając je oddzielnie , wszystko co robisz jest w ruchu startHttpServer 's idempotentność do kodu wzywając obie funkcje zamiast ... Poza tym, o ile nie zawijać zarówno logikę w trzeciej funkcji (co jest, co robi startHttpServerpo pierwsze), to zmusza cię do napisania nieSUSZONEGO kodu, powielając go wykładniczo wszędzie, gdzie będziesz musiał zadzwonić startHttpServer. Krótko mówiąc, startHttpServer musi nazywać się isHttpServerRunningfunkcją.

Więc mam na myśli:

• Zaimplementuj isHttpServerRunningfunkcję, ponieważ i tak może być potrzebna niezależnie ...
• Zaimplementuj startHttpServer, używając go isHttpServerRunningdo odpowiedniego zdefiniowania następnego działania ...

Mimo to możesz startHttpServerzwrócić dowolną wartość, której użytkownik tej funkcji może potrzebować, np .:

• 0 => błąd uruchamiania serwera
• 1 => serwer rozpoczął sukces
• 2 => serwer został już uruchomiony

Nazewnictwo funkcji

Po pierwsze, jaki jest główny cel użytkownika? Aby uruchomić serwer HTTP , prawda?

Zasadniczo nie ma problemu, zamierzając rozpocząć coś, co już rozpoczęto, AKA 1*1=1. Tak więc, przynajmniej dla mnie, nazwanie go „ ensureHttpServerIsRunning” nie wydaje się konieczne, bardziej zależałoby mi na tym, jak długa, naturalna i niezapomniana jest nazwa funkcji.

Teraz, jeśli chcesz wiedzieć, jak szczegółowo działa funkcja pod maską, istnieje do tego dokumentacja lub źródło kodu, mam na myśli, jak w przypadku każdej innej funkcji z biblioteki / frameworka / API / etc ...

Nauczysz się tej funkcji raz, pisząc ją wiele razy ...

W każdym razie trzymałbym się tego, startHttpServerco jest krótsze, prostsze i bardziej wyraźne niż ensureHttpServerIsRunning.

Przypuszczam, że twój kolega miał na myśli, że startHttpServerrobi zbyt wiele:

• Sprawdzanie, czy serwer już działa,
• Uruchamianie serwera w razie potrzeby.

To dwie niepowiązane części kodu. Na przykład podobna sytuacja występuje, gdy aplikacja komputerowa powinna upewnić się, że nie jest uruchomiona po uruchomieniu; będzie część kodu, która obsługuje instancje aplikacji (na przykład za pomocą muteksu) oraz kod, który uruchomi pętlę komunikatów aplikacji.

Oznacza to, że musisz mieć nie jedną, ale co najmniej dwie metody :

• isHttpServerRunning: boolean
• startHttpServer

Punkt wejścia aplikacji wywoła pierwszą metodę, a następnie drugą, jeśli zwracana jest wartość false. Teraz każda metoda robi jedną i jedną rzecz i jest łatwa do zrozumienia.

^{¹ Jeśli logika potrzebna do sprawdzenia, czy serwer już działa, jest zbyt złożona, może wymagać dalszego rozdzielenia na wiele metod.}

Ponieważ nie określasz języka, w JavaScript wiele bibliotek ma funkcję „raz”, np . Underscore . Więc jeśli byłoby ci to znane, nazwij to „raz” i prawdopodobnie zmień nazwę swojej metody.

Ja, pochodząc bardziej z Javy, przychodzą mi na myśl określenia „buforowanie” lub „leniwa ocena”. „Idempotent” jest technicznie poprawny i jest dobrym wyborem, szczególnie. jeśli masz bardziej funkcjonalne tło.

Wolę startHttpServerIfNotIsRunning.

W ten sposób warunek jest wyraźnie wymieniony już w nazwie metody. Ensurelub makeSurewydaje mi się nieco niejasny, ponieważ nie jest to wyrażenie techniczne. Wygląda na to, że nie wiemy dokładnie, co się wydarzy.

Twój kolega powinien był ci powiedzieć, że nie masz biznesu piszącego tą metodą. Jest już napisany wiele razy i napisany lepiej, niż można to napisać. Na przykład: http://docs.ansible.com/ansible/latest/systemd_module.html https://docs.saltstack.com/en/latest/ref/states/all/salt.states.service.html

Z architektonicznego punktu widzenia posiadanie dowolnego kodu zarządzającego serwerem WWW to koszmar. Chyba że zarządzanie usługami zależy wyłącznie od kodu użytkownika. Ale zgaduję, że nie napisałeś monit (ani kubernetes lub ...).