#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() // вызывается конкретным классом для уведомления слушателей о том, что задача выполнена
Итак, мои вопросы
- Эти имена в порядке или есть лучшие имена? Я подумал, что мог бы использовать «Commit» для NotifyTaskComplete, потому что он на самом деле транзакционный, а базовый класс также содержит функцию отката. Возможно, StartExecute следует просто выполнить (потому что задача не всегда будет асинхронной, как показано в Example2)
- Есть ли какие-либо другие функции, которые мне нужны? Я как-то испортил этот шаблон проектирования? Я видел примеры, когда люди используют асинхронный объект, но я думаю, что в данном случае это делает его менее интуитивным. Я хочу сосредоточиться на идее выполнения задачи, а не на идее, что у нее могут быть асинхронные функции.
Ответ №1:
Я бы предложил события, а не абстрактные методы, которые должны быть переопределены для обработки входящих данных или завершения этапа.
event EventHandler<StartedEventArgs> Started;
event EventHandler<CompletedEventArgs> Completed;
Комментарии:
1. Да, я предпочитаю события в целом, и я думаю, что это хорошая идея. В этом случае Started наверняка может быть событием … но завершенной будет функция, которую вы вызываете в какой-то момент, чтобы уведомить слушателей о том, что задача выполнена. Вы предлагаете мне использовать другое имя для полной функции … поскольку вы думали, что это событие, я уже вижу, что мое именование, вероятно, не очень хорошо.