Як називається функція, яка не приймає аргументів і нічого не повертає? [зачинено]

У java.util.functionпакеті Java 8 ми маємо:

• Функція : бере один аргумент, видає один результат.
• Споживач : Бере один аргумент, нічого не дає.
• Постачальник : не приймає аргументів, дає один результат.
• ... : Інші справи, що стосуються примітивів, 2 аргументи тощо ...

Але мені потрібно розібратися зі справою " не бере аргументів, нічого не дає ".

У цьому немає нічого java.util.functionnal.

Отже, питання:

Як називається функція, яка не бере аргументів і нічого не повертає ?

У Java 8 його визначення було б:

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

Виконавець вже існує і має іншу мету: " Об'єкт, який виконує подані завдання Runnable ". Підпис не відповідає ( execute(Runnable):void) і не є навіть функціональним інтерфейсом .

Виконання існує, але воно сильно пов'язане з контекстом нитки:

• Пакет є java.lang, ні java.util.function.
• Javadoc заявляє: " Інтерфейс Runnable повинен бути реалізований будь-яким класом, екземпляри якого призначені для виконання потоком ".
• Назва "Runnable" підказує деякий запущений код всередині потоку.

Вибір Яви зробити це таким чином з окремим ім'ям для кожної сукупності було дурним. Емуляції це не зовсім варто. Однак, якщо вам потрібно заради послідовності або ви пишете дуже загальний код бібліотеки, пропозиції Конрада хороші. Я можу кинути Procedureна ринг.

Використання псевдофункціональної парадигми не означає, що нормальні принципи іменування повинні виходити з вікна. Інтерфейси майже завжди повинні називатися тим, що вони роблять , а не за якоюсь загальною синтаксичною ідеєю. Якщо функції розміщені в стеку скасування, їх слід назвати UndoFunction. Якщо вони викликаються з подій GUI, вони повинні бути названі GUIEventHandler. Друзі не дозволяють друзям увічнювати погані угоди про іменування.

У світі java його називають Runnable. У світі C # його називають Action.

Але, є краща назва, яка чудово вписується в ширший погляд на речі.

Більш широке уявлення про речі з’являється пізніше, коли ви вирішите, що крім вашого параметричного недійсного функціонального інтерфейсу вам також потрібно мати подібні функціональні інтерфейси, які приймають один, два чи більше аргументів, або які повертають значення. Коли це станеться, ви хочете, щоб назви всіх цих утворень були ізоморфними та відповідали один одному.

Отже, у Java у мене є власний набір функціональних інтерфейсів, які я називаю Procedures, визначених так:

public interface Procedure
{
    void invoke();
}

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

... (ви отримуєте малюнок.)

І у мене також є аналогічний набір інтерфейсів під назвою Functions, визначений аналогічно, причому перший загальний параметр є типом повернення:

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

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

Отже, моя думка в тому, що Procedureце дуже гарне ім'я, тому що воно добре вписується в ширший погляд на речі. Якщо згодом ви вирішите мати подібні функціональні інтерфейси з методами, які приймають аргументи або повертають значення, ви зіткнетеся з цим.

ПРИМІТКА: Я в основному погоджуюся з твердженням Карла Білефельдта про те, що "нормальні принципи іменування повинні [не] виходити з вікна" і "Інтерфейси майже завжди повинні називатися тим, що вони роблять, а не за якоюсь загальною синтаксичною ідеєю". Але зауважте, що навіть він дозволяє це «майже завжди». Іноді виникає потреба у (по суті анонімних) процедурах та функціях, і це те, про що задається ОП, і саме це я відповідаю.

Поправка 2017-11-10:

Ви можете запитати, чому Function1<R,T1>замість цього Function1<T1,R>? Це може піти в будь-який бік, але я маю перевагу повернутих значень зліва, тому що мені подобається дотримуватися конвенції іменування "конвертувати з" (призначення-з-джерела) на відміну від "перетворити в" (джерело-в) -дестинація) конвенція. (Що насправді скоріше випадковість, ніж конвенція, в тому сенсі, що, швидше за все, ніхто ніколи не думав про це, бо якби вони взагалі не задумалися, вони приїхали б до конвенції "перетворення з". )

Про це я читав у Joel Spolksy - Зробити невірний код Помилковим , це дуже довга стаття, яку я рекомендую прочитати в повному обсязі, але якщо ви хочете перейти прямо до справи, знайдіть "TypeFromType", але в дамо вам TL; DR, ідея полягає в тому, що myint = intFromStr( mystr )це набагато краще myint = strToInt( mystr ), тому що в першому випадку назви типів близькі до пов'язаних значень, тому ви можете легко побачити, що 'int' збігається з 'int' і 'str' збігається з 'str'.

Отже, розширення я схильний впорядковувати речі так, як вони збираються відображатися в коді.

Чому ні Command? Зважаючи на те, що він не бере даних і не повертає даних, але припускаючи, що викликати це викликає певний ефект (інакше це було б досить безглуздо), я думаю, що це єдине, що він може зробити - запустити дію, зробити щось.

Якщо говорити про це, Actionу .NET також є загальний делегат. На відміну від Java, Consumerвона може приймати від 0 до 16 аргументів; Іншими словами, найпростіша його версія не має жодної - див. MSDN .

А оскільки ім’я не означає, що є що-небудь "споживати", це також здається хорошим вибором імені.