⚡️Вести с полей - Duit

Я не просто инженер, я овер-инженер! И вот с пакетами flutter_duit и duit_kernel я наоверинженерил знатно. Айда разбираться!

Начнем с того, что в разработке библиотек и SDK есть масса нюансов, одним из которых является контроль публичного API. Хороший тон - это когда кишки библиотеки (утилитарные сущности, внутренние классы, дтошки и тд) не торчат наружу, а пользователь получает лаконичный и понятный API. Это знание пригодится нам в будущем.

И вот давеча, я нащупал занимательный факт о том, как устроена работа с Duit. Итак, следите за руками... Фреймворк поставляется в виде пакета flutter_duit. Пакет flutter_duit зависит от пакета duit_kernel (набор базовых абстракций). Чтобы использовать, например, кастомные виджеты, одного лишь flutter_duit недостаточно, потребуется напрямую установить в проекте версию duit_kernel, который является транзитивной (косвенной) зависимостью flutter_duit. Запутанно? Согласен! К чему это приводит? К замешательству при попытке неопытного юзера внедрить библиотеку.

Тут-то у меня и промелькнула замечательная мысль - "а почему бы не взять и экспортировать сущности из duit_kernel в качестве публичного API flutter_duit?". И, к слову, это вполне легальный способ решить эту запару с зависимостями. Но и тут есть подводные камни.

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

И даже из этого положения есть выход! Можно не экспортировать сущности напрямую, а создавать классы-обертки, которые наши зависимости и развернут. В таком подходе есть неоспоримый плюс - бОльшая устройчивость публичного API flutter_duit, поскольку мы инкапсулируем реальный интерфейс сущности и защищаемся от потенциальный breaking changes. С другой стороны мы получаем в нагрузку набор прослоек, задача которых просто обеспечивать нужный контракт.

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