Qual è il nome di una funzione che non accetta argomenti e non restituisce nulla? [chiuso]

Nel java.util.functionpacchetto di Java 8 abbiamo:

• Funzione : accetta un argomento, produce un risultato.
• Consumatore : accetta un argomento, non produce nulla.
• Fornitore : non accetta argomenti, produce un risultato.
• ... : altri casi che trattano primitivi, 2 argomenti, ecc ...

Ma devo gestire il caso " non prende argomenti, non produce nulla ".

Non c'è niente per questo in java.util.functionnal.

Quindi, la domanda è:

Qual è il nome di " una funzione che non accetta argomenti e non restituisce nulla "?

In Java 8, la sua definizione sarebbe:

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

Executor esiste già e ha un altro scopo: " Un oggetto che esegue attività eseguibili inviate ". La firma non corrisponde ( execute(Runnable):void) e non è nemmeno un'interfaccia funzionale .

Eseguibile esiste, ma è fortemente collegato al contesto di threading:

• Il pacchetto java.langnon lo è java.util.function.
• Il javadoc afferma: " L'interfaccia Runnable dovrebbe essere implementata da qualsiasi classe le cui istanze sono destinate ad essere eseguite da un thread ".
• Il nome "Runnable" suggerisce un codice in esecuzione all'interno di un thread.

La scelta di Java di farlo in quel modo con un nome separato per ogni arità era stupida. Non vale esattamente la pena di emularlo. Tuttavia, se è necessario per motivi di coerenza o se stai scrivendo un codice di libreria molto generico, i suggerimenti di Konrad sono validi. Potrei buttarmi Proceduresul ring.

L'uso di un paradigma pseudo-funzionale non significa che i normali principi di denominazione dovrebbero uscire dalla finestra. Le interfacce dovrebbero quasi sempre avere il nome di quello che fanno , non dopo qualche idea sintattica generica. Se le funzioni vengono inserite in uno stack di annullamento, devono essere denominate UndoFunction. Se vengono chiamati dagli eventi della GUI, devono essere nominati GUIEventHandler. Gli amici non consentono agli amici di perpetuare convenzioni di denominazione sbagliate.

Nel mondo Java, si chiama Runnable. Nel mondo C #, si chiama Action.

Ma esiste un nome migliore che ben si adatta a una visione più ampia delle cose.

La visione più ampia delle cose arriva più tardi, quando decidi che oltre alla tua interfaccia funzionale vuota senza parametri devi anche avere interfacce funzionali simili che accettano uno, due o più argomenti, o che restituiscono un valore. Quando ciò accade, vorrai che i nomi di tutte quelle entità siano isomorfi e corrispondenti tra loro.

Quindi, in Java, ho il mio set di interfacce funzionali che chiamo Procedures, definito come segue:

public interface Procedure
{
    void invoke();
}

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

... (ottieni l'immagine.)

E ho anche un set simile di interfacce chiamato Functions, definito in modo simile, con il primo parametro generico che è il tipo restituito:

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

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

Quindi, il mio punto qui è che Procedureè un ottimo nome perché si adatta perfettamente a una visione più ampia delle cose. Se in seguito decidi di avere interfacce funzionali simili con metodi che accettano argomenti o restituiscono un valore, ti imbatterai in questo.

NOTA: concordo sostanzialmentecon l'affermazione di Karl Bielefeldt secondo cui "i normali principi di denominazione dovrebbero [non] uscire dalla finestra" e che "Le interfacce dovrebbero quasi sempre avere il nome di ciò che fanno, non dopo qualche idea sintattica generica". Ma nota che anche lui permette "quasi sempre". A volte sono necessarie procedure e funzioni (essenzialmente anonime), ed è quello che l'OP sta chiedendo, ed è quello a cui sto rispondendo.

Emendamento 10-11-2017:

Potresti chiedere, perché Function1<R,T1>invece di Function1<T1,R>? Potrebbe andare in entrambi i modi, ma ho una preferenza per i valori di ritorno a sinistra perché mi piace seguire la convenzione di denominazione 'convert-from' (destination-from-source) rispetto alla 'convert-to' (source-to -destinazione) convenzione. (Che è più un incidente che una convenzione, davvero, nel senso che molto probabilmente nessuno ci ha mai pensato, perché se ci avessero pensato, sarebbero arrivati ​​alla convenzione "convertiti da". )

Ho letto di questo in Joel Spolksy - Far sembrare sbagliato il codice sbagliato , è un articolo molto lungo, che consiglio di leggere nella sua interezza, ma se vuoi saltare direttamente al caso in esame, cerca "TypeFromType", ma per darti il ​​TL; DR, l'idea è myint = intFromStr( mystr )molto meglio di myint = strToInt( mystr ), perché nel primo caso i nomi dei tipi sono vicini ai valori associati, quindi puoi facilmente vedere che 'int' corrisponde a 'int' e lo "str" ​​corrisponde allo "str".

Quindi, per estensione, tendo a ordinare le cose nel modo in cui appariranno nel codice.

Perché no Command? Dato che non prende dati e non restituisce dati, ma supponendo che chiamarlo causi qualche effetto (altrimenti sarebbe piuttosto inutile davvero), immagino che sia all'incirca l'unica cosa che può fare: sparare un'azione, far accadere qualcosa.

A proposito, c'è anche un Actiondelegato generico in .NET. A differenza di Java, Consumerpuò richiedere da 0 a 16 argomenti; in altre parole, la versione più semplice non ne accetta nessuna - vedi MSDN .

E poiché il nome non implica che ci sia qualcosa da "consumare", sembra anche una buona scelta per il nome.