Я хочу использовать наиболее интуитивно понятный шаблон асинхронного проектирования и нужные функции и правильное именование

#design-patterns

#шаблоны проектирования

Вопрос:

Мне нужно создать базовый класс с абстрактной функцией, которая может быть асинхронной. Обычно я бы не стал заниматься правильным присвоением имен и функций, но мой класс является частью SDK, поэтому мне нужно, чтобы он был как можно более понятным и максимально приближенным к стандарту сообщества.

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

 //asynchronous
class TalkToServer : TaskBase {

   void override StartExecute(){
       Server s = new Server();
       s.HandleResponse  = new ReponseEvent(GotResponse);
       s.AskTheServer();
   }

   void GotResponse(Server s){
       //do stuff with response
       base.NotifyTaskComplete();
   }
}

//this could also happen (synchronous)
class Example2: TaskBase {

   void override StartExecute(){
       //do stuff
       base.NotifyTaskComplete();
   }
}
  

Итак, единственными функциями, которые у меня есть в моем базовом классе для обработки асинхронных процедур, являются:

  • StartExecute() // вызывается, когда готов начать выполнение задачи
  • NotifyTaskComplete() // вызывается конкретным классом для уведомления слушателей о том, что задача выполнена

Итак, мои вопросы

  1. Эти имена в порядке или есть лучшие имена? Я подумал, что мог бы использовать «Commit» для NotifyTaskComplete, потому что он на самом деле транзакционный, а базовый класс также содержит функцию отката. Возможно, StartExecute следует просто выполнить (потому что задача не всегда будет асинхронной, как показано в Example2)
  2. Есть ли какие-либо другие функции, которые мне нужны? Я как-то испортил этот шаблон проектирования? Я видел примеры, когда люди используют асинхронный объект, но я думаю, что в данном случае это делает его менее интуитивным. Я хочу сосредоточиться на идее выполнения задачи, а не на идее, что у нее могут быть асинхронные функции.

Ответ №1:

Я бы предложил события, а не абстрактные методы, которые должны быть переопределены для обработки входящих данных или завершения этапа.

 event EventHandler<StartedEventArgs> Started;
event EventHandler<CompletedEventArgs> Completed;
  

Комментарии:

1. Да, я предпочитаю события в целом, и я думаю, что это хорошая идея. В этом случае Started наверняка может быть событием … но завершенной будет функция, которую вы вызываете в какой-то момент, чтобы уведомить слушателей о том, что задача выполнена. Вы предлагаете мне использовать другое имя для полной функции … поскольку вы думали, что это событие, я уже вижу, что мое именование, вероятно, не очень хорошо.