Как я и говорил в прошлый раз, ключ к читаемому и поддерживаемому коду – отделение кода многопоточности от кода приложения. Об этом писал еще Фаулер (Martin Fowler) в своей библии PoEAA. Вынести многопоточность на уровень инфраструктуры очень заманчиво, и… вполне возможно! Но с помощью голого .NET этот узел не разрубить.
Приступая к проектированию какой-либо библиотеке, надо аккуратно продумать продумать вопрос API и абстракций, которые она предоставляет. И API, и абстракции должны быть чертовски просты. В ином случае остаётся слишком много возможностей для клиентского кода, что увеличивает сложность.
public interface ITask | |
{ | |
void Execute(); | |
} | |
public interface IExecutor | |
{ | |
void Execute(ITask task) | |
} |
Мне очень нравятся эти интерфейсы. Они просты, и разделяются две очень важные вещи: действие от момента его исполнения. Просим выполнить задачу, и всё. Когда она выполнится – решит реализация IExecutor. Стоит отметить, что для успешного применения код приложения должен быть написан в стиле, который исключает предположения о моменте и порядке выполнения задач. В противном случае получается транзитивная связность между клиентским и инфраструктурным кодом. Такой код тяжело понимать, отлаживать и тестировать.
Задача простоты тестирования для таких абстракций упрощается – необходимости тестировать многопоточный код нет. Он протестирован на уровне реализации IExecutor. А любую реализацию ITask легко тестировать, вызывая Execute в синхронном режиме.
Собственно, про API всё. В следующий раз расскажу, как я ошибся с первой реализаций, и почему это была ошибка.
Комментариев нет:
Отправить комментарий