Комментарии 14
решение, которое первое приходит в голову
оно прекрасно
Извините, но вы написали код а потом притянули на него ваше понимание SOLID.
Накидают вам в комментах.
"В результате получилось, что нет того функционала, который бы не был востребован, есть только все самое нужное и актуальное."
- Вовсе нет.
GetConnection() используется внутри GetCalendar(). Делать его публичным нету смысла. Так как запросто можно его вызвать в открытую и не закрыть Connection. Второе, а что делать, если у каждого клиента поменялся Connection? Нужен способ задавать ConnectionStrings, по которым DbWorker-ы подключаются к базе. Для этого необходимо определить интерфейс настройки Worker-а (какой-нибудь IWorkerManager).
Вы правы. Но как мы говорили несколько раз в публикации, в данных примерах мы старались максимально упросить логику, поскольку статья ориентирована на тех, кто начинает знакомство с программированием. Некоторые вещи утрированы для простоты понимания.
По итогу - лёгкий код превратили в сложный
Настолько утрированы, что Worker занимается не только подключением и выполнением запроса к базе, но и чтением РЕЗУЛЬТАТА, извлечением и преобразованием данных. Сразу нарушение Single Responsibility. Потому что название лишь говорит о том, что она работает с базой, и всё. Возможно, нам, например, захочется тестировать преобразование данных (формат дат из одной культуры в другую, к примеру из 23.10.2022 в 2022/10/23). И нам не потребуется работать с базой. Но у нас кроме workers пока ничего нет. Или мы получаем данные в виде JSON из базы. Worker-у не надо знать JSON, CSS, CSV и другие форматы лишь чтобы вернуть корректный результат. Он лишь возвращает ответ из базы и всё. А приведение ответа из базы к адекватному формату - другая сущность.
Знаете, я много раз замечал: если человек неграмотен, то он неграмотен во всём примерно одинаково.
Если вы постоянно пишете holydays и emplyee, то ждать грамотного подхода от всей статьи не приходится. Так и вышло: (N+1)-я попытка разжевать SOLID вышла слегка неграмотной.
В целом ничего страшного, мы уже привыкли, из предыдущих N статей на ту же тему нормальных было, наверное, одна или две..
Хорошая статья. Хорошо показывает, зачем и как можно использовать принципы SOLID. Эти принципы просты только для тех, кто из уже хорошо понимает и/или хорошо подкован в программировании вообще и архитектуре в частности, а для джунов эти принципы сложны, как раз из-за недостатка опыта сложно увидеть грабли. Статья на хорошем примере показывает, что бывает без этих принципов.
Понятно, что в статье пришлось убрать некоторые вещи, на которые указали в комментах. Если это всё это сделать, то статья станет в три раза больше и в десять раз сложнее, и не поможет джунам понять принципы.
Допустим у нас SOLID. Все хорошо? Не факт, но неплохо.
Допустим у нас дикий треш, как его довести до ума? Вероятно переписать все напрочь. Статья про это же?
Я извиняюсь, но тут вступает принцип Kiss. Написать скрипт который берет записи не старше суток и закинул в крон на нужное время и дни.
Создание новых абстракций решает все проблемы кроме проблемы слишком большого количества абстракций.
Принципы Solid и как они помогают сделать код лучше