Должна ли моя общая реализация Future иметь событие Completed? - PullRequest
Новая
       17

Должна ли моя общая реализация Future иметь событие Completed?

1 голос
/ 27 июня 2011

Я пишу универсальный класс Future<T>, который инкапсулирует получение значения асинхронно, и я заметил, что большинство существующих реализаций в сети имеют такой контракт: 

public class Future<T>
{
    public Future(Func<T> func); // kicks off the async operation
    public T Value { get; } // gets the value and blocks if the async operation isn't done
}

Это немедленно заставляет меня захотеть добавить событие Completed в реализацию, чтобы мне не приходилось запрашивать значение, когда я хочу получить асинхронное значение, и знать, когда это будет сделано. Я заметил, что библиотека параллельного программирования реализует фьючерсы таким образом, но мне было любопытно, почему во многих реализациях нет этого события. Я что-то пропустил? Должен ли Фьючерс иметь Завершенное событие или нет? Или это просто зависит от вашего контекста?

Ответы [ 2 ]

3 голосов
/ 28 июня 2011

Я думаю, что иметь что-то подобное в качестве события или метод, который принимает делегат для продолжения , полезно в универсальном Future<T>. Если вы создаете его только для определенной цели, это может не понадобиться.

Кроме того, имейте в виду, что примеры в сети часто являются именно этим, а не кодом производственного качества, и они могут пропустить функции, которые на самом деле не нужны, но все же полезны, такие как этот.

Еще одна вещь, на которую следует обратить внимание, это то, что ваша работа может вообще не понадобиться, поскольку эта функциональность уже находится в фреймворке в виде Task<T>.

2 голосов
/ 28 июня 2011

Я думаю, что это несколько запутывает концепцию будущего.На мой взгляд, весь смысл будущего заключается в том, что они позволяют вам использовать значения, которые вычисляются асинхронно в коде, который в противном случае является последовательным.Если желателен более откровенный асинхронный стиль, то это то, для чего нужна передача с продолжением.Класс Task в .NET сочетает в себе поддержку обоих стилей, и до сих пор я был полностью этому доволен.Тем не менее, я стараюсь разделить эти два стиля: если я планирую форсировать задачу, я предпочитаю избегать присвоения ей каких-либо продолжений и наоборот.

...