Сервисы: строим масштабируемые и гибкие приложения с помощью чистой архитектуры

[PackRuble]

Спасибо за статью, посылы несёте праведные! Хочу обратить внимание на некоторые вещи:

1. У вас слетели отступы (для dart обычно принят отступ в два пробела)

2. Чем продиктована необходимость использовать префикс I для именования интерфейсов? Былой разработкой на java?)) Есть мнение, что лучше именовать реализации интерфейсов, добавляя постфикс Impl (вот так: ClipboardServiceImpl -> ClipboardService), тогда ваша бизнес-логика не имеет лишней семантической сложности.

3. Стоит заметить, что для простых приложений лучше воспользоваться как раз таки if-else реализациями, нежели чем плодить абстракции абстракций интерфейсов :) В данном случае может показаться, что сделать интерфейс для сервиса достаточно просто. Но вспомните реальные кейсы с необходимой реализацией 10-20 методов. Мой вердикт - by design. Внедряем, если есть неотрицательная вероятность "бизнес захочет"

4. Используйте interface class или даже abstract interface class вместо abstract class, чего стесняться, если dart 3 разрешает

[kaparray]

Добрый день! Спасибо за комментарий. Отвечаю на ваши пункты:
1) спасибо
2) Думаю это вопрос "вкусовщины". Я считаю что интерфейс должен быть явно выделен. То есть название должно быть i_name_of_class.dart и имя класса INameOfClass. Это позволяет более явно отделить интерфейсы от реализации.
3) Моё мнение "всегда нужно исходить из бизнес потребностей".
4) Согласен. Вы уже мигрировали свой проект на dart 3? Расскажите опыт.

[kacetal]

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

А вот имплементации могут быть максимально "некрасивыми" *Impl, *Test, *Mock итд. Так как мы их видим только при декларации и пользуемся только абстракцией.

[PackRuble]

Да, миграция на dart 3 оказалась вполне приятной. Возможно, в силу специфичности моих проектов, но:

• в приложении Weather Today это выглядело буквально вот так commit. При чём проект не обновлялся полгода и только поэтому я сделал такой непринуждённый обобщённый коммит, обновив сразу все доступные зависимости. Но для dart 3 этого не требовалось. Всё сразу заработало без танцев

• в пакете weather_pack тоже всё прошло легко. Но проект совсем простой, это плохое сравнение с бизнес кейсами

• прямо сейчас происходит миграция одного чуть бОльшего приложения чем погодка, с кучей устаревших зависимостей (даже форков для которых нет) и с флагом --no-sound-null-safety в командной строке при запуске/билде. В текущую минуту уже избавились от флага и на стадии "а не накатить ли dart 3", но:

  • если форков нет, нужно самому править пакеты, что занимает много времени

  • лучше потратить время на работу с кодовой базой, которая тоже не ахти (включая архитектуру)

  • в этом проекте нет нужды ни в pattern matching, ни в switch expressions, ни в модификаторах классов

Плюс в том, что некоторые популярные пакеты уже перешли на новую версию и мы этого можем даже не замечать, если автор указал минорное|патч повышение версии. И также жизнь облегчает то, что pub tool пока что позволяет ставить пакеты даже с ограничением а-ля sdk: '>=2.14.0 <3.0.0':

Dart’s pub tool allows resolution even when the upper bound is limited to versions below 3.0.0. For example, a package with the following constraint will be allowed to resolve with a Dart 3.x SDK, as pub will re-interpret the upper-constraint <3.0.0 as <4.0.0 when the lower constraint is 2.12 or higher

Опять же, когда я попробовал switch выражения, то забыл об идиотском обходе используя анонимные функции или "большом разглагольствовании". Когда я попробовал сопоставление (вместе с sealed) - пришлось привыкать к новому синтаксису, но оказалось вполне удобным. Records оказались также весьма кстати. Модификаторы - это для ультра проектов, либо для повышенного удобства использования пакетов (для авторов пакетов). А вот различные виды сопоставлений не могу освоить до сих пор (имеется ввиду, чтобы их восприятие стало для меня родным и удобным). Лично мне сейчас очень не хватает data-классов, метапрограммирования и нормального ide-рефакторинга.