Jak nazywa się funkcja, która nie przyjmuje argumentów i nic nie zwraca? [Zamknięte]

W java.util.functionpakiecie Java 8 mamy:

• Funkcja : Bierze jeden argument, daje jeden wynik.
• Konsument : bierze jeden argument, nic nie produkuje.
• Dostawca : Nie bierze argumentu, daje jeden wynik.
• ... : Inne sprawy obsługujące operacje podstawowe, 2 argumenty itp.

Ale muszę sobie poradzić z przypadkiem „ nie bierze argumentu, nic nie produkuje ”.

W tym nie ma nic java.util.functionnal.

Pytanie brzmi:

Jak nazywa się „ funkcja, która nie przyjmuje argumentów i niczego nie zwraca ”?

W Javie 8 jego definicją byłoby:

@FunctionalInterface
public interface InsertANameHere {
    void execute();
}

Executor już istnieje i ma inny cel: „ Obiekt, który wykonuje przesłane zadania Runnable ”. Podpis nie pasuje ( execute(Runnable):void) i nie jest nawet funkcjonalnym interfejsem .

Runnable istnieje, ale jest silnie powiązany z kontekstem wątków:

• Pakiet java.langnie jest java.util.function.
• Jawadoc stwierdza: „ Interfejs Runnable powinien być implementowany przez każdą klasę, której instancje mają być wykonywane przez wątek ”.
• Nazwa „Runnable” sugeruje trochę działającego kodu w wątku.

Wybór Javy, aby zrobić to w ten sposób z osobną nazwą dla każdego ariana, był głupi. Nie jest to warte naśladowania. Jeśli jednak musisz zachować spójność lub piszesz bardzo ogólny kod biblioteki, sugestie Konrada są dobre. Mogę rzucić Procedurew pierścień.

Użycie pseudo-funkcjonalnego paradygmatu nie oznacza, że ​​normalne zasady nazewnictwa powinny wyjść z okna. Interfejsy należy prawie zawsze nazywać po tym, co robią , a nie po ogólnym pomyśle syntaktycznym. Jeśli funkcje zostaną umieszczone w stosie cofania, należy je nazwać UndoFunction. Jeśli są wywoływane ze zdarzeń GUI, należy je nazwać GUIEventHandler. Przyjaciele nie pozwalają przyjaciołom utrwalać złych konwencji nazewnictwa.

W świecie Java nazywa się to Runnable. W świecie C # nazywa się to Action.

Ale istnieje lepsza nazwa, która ładnie pasuje do szerszego widoku rzeczy.

Szerszy widok rzeczy pojawia się później, gdy zdecydujesz, że oprócz twojego pozbawionego parametrów pustego interfejsu funkcjonalnego potrzebujesz także podobnych interfejsów funkcjonalnych, które akceptują jeden, dwa lub więcej argumentów lub zwracają wartość. Kiedy tak się stanie, będziesz chciał, aby nazwy wszystkich tych bytów były izomorficzne i korespondowały ze sobą.

Tak więc w Javie mam własny zestaw interfejsów funkcjonalnych, które nazywam Procedures, zdefiniowane w następujący sposób:

public interface Procedure
{
    void invoke();
}

public interface Procedure1<T1>
{
    void invoke( T1 argument1 );
}

... (Dostajesz obraz.)

Mam również podobny zestaw interfejsów o nazwie Functions, zdefiniowany w podobny sposób, przy czym pierwszym parametrem ogólnym jest typ zwracany:

public interface Function<R>
{
    R invoke();
}

public interface Function1<R,T1>
{
    R invoke( T1 argument1 );
}

Chodzi mi o to, że Procedurejest to bardzo dobre imię, ponieważ ładnie pasuje do szerszego widoku rzeczy. Jeśli później zdecydujesz się na podobne interfejsy funkcjonalne z metodami, które akceptują argumenty lub zwracają wartość, natkniesz się na to.

UWAGA: Zasadniczo zgadzam się z twierdzeniem Karla Bielefeldta, że ​​„normalne zasady nazewnictwa powinny [nie] wychodzić z okna” i że „interfejsy należy prawie zawsze nazywać po tym, co robią, a nie po ogólnym pomyśle syntaktycznym”. Pamiętaj jednak, że nawet on pozwala na „prawie zawsze”. Czasami potrzebne są (zasadniczo anonimowe) procedury i funkcje, i właśnie o to prosi OP, i na to odpowiadam.

Poprawka 2017-11-10:

Możesz zapytać, dlaczego Function1<R,T1>zamiast Function1<T1,R>? Może pójść w obie strony, ale preferuję zwracanie wartości po lewej stronie, ponieważ lubię stosować konwencję nazewnictwa „konwersja z” (miejsce docelowe z źródła) w przeciwieństwie do „konwersji do” -destination) konwencja. (Co jest bardziej wypadkiem niż konwencją, w rzeczywistości w tym sensie, że najprawdopodobniej nikt nigdy nie zastanawiał się nad tym, ponieważ gdyby w ogóle się nad tym zastanowili, doszliby do konwencji o nawróceniu. )

Przeczytałem o tym w Joel Spolksy - Sprawianie, że zły kod wygląda źle , jest to bardzo długi artykuł, który polecam przeczytać w całości, ale jeśli chcesz przejść bezpośrednio do omawianej sprawy, wyszukaj „TypeFromType”, ale aby dać TL; DR, pomysł jest o myint = intFromStr( mystr )wiele lepszy niż myint = strToInt( mystr ), ponieważ w pierwszym przypadku nazwy typów są zbliżone do powiązanych wartości, dzięki czemu można łatwo zobaczyć, że „int” pasuje do „int” i „str” pasuje do „str”.

Tak więc, przez rozszerzenie, mam tendencję do porządkowania rzeczy w taki sposób, w jaki będą wyglądały w kodzie.

Dlaczego nie Command? Biorąc pod uwagę, że nie wymaga danych i nie zwraca żadnych danych, ale zakładając, że wywołanie go powoduje jakiś efekt (w przeciwnym razie byłoby to raczej bezcelowe), wyobrażam sobie, że jest to z grubsza jedyna rzecz, jaką może zrobić - uruchomić akcję, sprawić, by coś się stało.

Mówiąc o tym, istnieje również ogólny Actiondelegat w .NET. W przeciwieństwie do Javy Consumermoże zająć od 0 do 16 argumentów; innymi słowy, najprostsza wersja tego nie wymaga - patrz MSDN .

A ponieważ nazwa nie sugeruje, że ma się co „konsumować”, wydaje się, że to dobry wybór.