Обновить
2
Aliaksei Radzevich@aradzevich

ex-Yandex | C++, .Net | High load, Low latency

1
Подписчики
Отправить сообщение

Да, пожалуй соглашусь с вами, это интересное замечание. Я постарался хотя бы частично учесть его в README и точно учту в следующей статье.

Согласен с обоими пунктами, пришёл к тем же выводам, пока делал библиотеку.
Но решить проблему отсутствия концептов частично всё-таки можно.

Для этого нужно объявить члены шаблонного аргумента внутри соответствующего ему типа-дескриптра.

struct UnitOfWorkDescriptor {
    int AddDepartment(const std::string& departmentName);
    int AddEmployee(int departmentId, const std::string& employeeName);
    void RemoveDepartment(int departmentId);
    void RemoveEmployee(int departmentId, int employeeId);
    ...
};

Поскольку дескриптор подставляется как тип по умолчанию, автокомплит начнёт работать. Очевидный минус - обновлять методы нужно не только в реализации, но и в деcкрипторе.

Подход из статьи должен как раз решить часть ваших болей: благодаря тому, что подставляемый тип будет известен уже на этапе компиляции, IDE сможет вам подсказать, какую именно реализацию класса вы используете:


Большое спасибо за развёрнутый комментарий, многие мысли резонируют с моими собственными.

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

Примеры в статье взяты из моего бэкендского опыта и представляют из себя части тех самых больших и неуклюжих программ. Недостаток контекста может создавать ощущение искусственности этих примеров. И это ощущение тем сильнее, чем дальше читатель по своему направлению деятельности от разработки бэкэнда. Использование в качестве примеров WTL -компонентов может иметь обратный эффект - уже бэкэнд-разработчики посчитают их высосанными из пальца.

Тем не менее у меня не достаточно знаний, чтобы судить об этом с полной уверенностью. Возможно, примеры с использование GUI действительно окажутся куда более иллюстративными, выразительными и понятными большему количеству людей. Я познакомлюсь ближе с этой библиотекой, благодарю вас за подсказку.

Большое спасибо, исправил.

Согласен, через интерфейсы было бы проще и привычнее, да и материалов про это в интернете куда больше, чем про внедрние зависимостей через шаблоны. Это хорошо при выборе технологии для использовании в продакшене, но является скорее минусом при написании статьи - не хочется повторятся, хотчется пробовать что-то новое или хотя бы не заезженное.

Если говорить про сложность для программиста, который будет библиотекой пользоваться, то я старался сделать её максимально похожей на аналоги, которые работают с интерфейсами. Главное отличие в том, что вместо интерфейсов используются дескрипторы.

Безусловно, я согласен, что такой подход имеет свои недостатки в сравнении с интерфейсами. Например, разнесения кода шаблонного класса по .h и .cpp файлам становится сущей головной болью. Но хочется верить, что для программ, которые работают в режиме реального времени и не допускают использования позднего связывания, это может оказаться допустимыми неудобствами.

Информация

В рейтинге
Не участвует
Откуда
Беларусь
Зарегистрирован
Активность

Специализация

Бэкенд разработчик, Архитектор программного обеспечения
Старший
От 6 000 $
C++
C#
Распределённые вычисления
Микросервисная архитектура
ООП
Linux
Многопоточность
Базы данных
Высоконагруженные системы
Проектирование архитектуры приложений