Оптимизация архитектуры: делим крупные классы с помощью миксинов

Всем привет! Это статья для тех, кто интересуется фреймворком Flutter и языком Dart. На связи Николай Омётов, руководитель Flutter разработки IT-компании Mad Brains. Сегодня обсудим, как делить большой файл класса с помощью миксинов. 

Для начала давайте разберемся, зачем вообще делить большой файл класса?

Причин несколько: во-первых, чтобы было удобно читать и рефакторить код. Во-вторых, чтобы уменьшить количество конфликтов при merge и разделении истории git в конкретном файле. Согласитесь, отследить историю изменений в разных маленьких файлах удобнее и быстрее, чем в одном большом, с разнообразием изменений. 

Рассмотрим пример проблемы?

Для общения с сервером у нас используется класс, реализующий RestService-интерфейс.

abstract interface class RestService{   const RestService();      String getProfileData();   void logout();   // ... и ещё много методов, пускай 52 } 

Само по себе это выглядит «почти» нормальным (об этом далее). Как пример, разработчик взял всего 52 строки с описанием сигнатур функций, но дальше реализация каждой функции будет занимать все больше и больше места:

class RestServiceMock implements RestService{   const RestServiceMock();      @override   void logout() => print('logout mock');      @override   String getProfileData() => 'getProfileData mock';      // На каждый метод уже 2 строки } 

class RestServiceImpl extends RestServiceMock {   const RestServiceImpl();      final String name = 'Акакий';      @override   void logout() {     _getToken();     print('logout $name');   }      @override   String getProfileData() => 'getProfileData: $name';      void _getToken() => print('Here we get Token'); }

Как решать задачу

Если в интерфейсе слишком много методов, это повод задуматься, не нарушаем ли мы принципы SOLID, а именно Interface Segregation.

«Толстые» интерфейсы необходимо разделять на более мелкие и специфичные, чтобы программные сущности маленьких интерфейсов знали только о тех методах, которые необходимы им в работе.

Реализовать это можно: в Swagger запросы обычно разделены на группы, такие как авторизация, профиль и т.д. На основе них можно разделить и классы.

Однако есть нюанс: при таком делении в DI (Dependency Injection) появится больше классов-зависимостей (например, ProfileApi, AuthApi) вместо одного RestService. То есть в логику (в нашей архитектуре этоInteractor‘ы) можно будет передавать отдельные интерфейсы групп запросов.

С одной стороны, это удобно — можно иметь доступ только к функциям группы. С другой, есть проблема: придется каждый раз добавлять новую группу, если нужный метод находится только в ней, хотя раньше все методы были доступны в RestService.

В Dart можно добавить к классу несколько интерфейсов, так что можно создать RestServiceImpl, который реализует все нужные интерфейсы и методы. Через DI мы будем обращаться к нему, используя только нужный интерфейс. В результате вместо одного большого RestService получим множество файлов для каждой группы и их реализаций. Получается проблема, озвученная в самом начале, решена? — Да, и это классический подход, верный по SOLID, который удобен, если, например, одна из групп (скажем, авторизация) перейдёт на другой сервис, такой как GraphQL.

Задействуем миксины

Есть и другой способ поделить крупные классы — можно использовать миксины. Этот подход заключается в том, чтобы вынести реализацию методов в mixin’ы и хранить их в отдельных файлах. Никакие дополнительные внедрения в DI не нужны, новые файлы будут состоять только из миксинов, и в архитектуре новых сущностей не появится.

mixin AuthPart on RestServiceImpl {   @override   void logout() {     _getToken();     print('logout $name');   } }  mixin ProfilePart on RestServiceImpl {   @override   String getProfileData() => 'getProfileData: $name'; } 

Но как подключать миксины? Смотрите, в Dart есть интересная возможность 👇

// Создаём приватный сервисный класс наследник от реализации (RestServiceImpl) // Который использует все наши миксины с реализацией методов (AuthPart, ProfilePart) class _RestApiSplitedService extends RestServiceImpl with AuthPart, ProfilePart {    _RestApiSplitedService() : super._(); }  // Определяем у RestServiceImpl стандартный конструктор как factory, в котором подменяем его на _RestApiSplitedService. class RestServiceImpl extends RestServiceMock {   const RestServiceImpl._();      factory RestServiceImpl() = _RestApiSplitedService;      final String name = 'Акакий';      void _getToken() => print('Here we get Token'); } 

Таким образом, нам будет казаться, что мы используем RestServiceImpl, а при вызове runtimeType окажется, что это _RestApiSplitedService.

void main() async {   final RestServiceImpl restService = RestServiceImpl();     print(restService.getProfileData());     restService.logout(); }  abstract interface class RestService{   const RestService();      String getProfileData();   void logout(); }  class RestServiceMock implements RestService{   const RestServiceMock();      @override   void logout() => print('logout mock');      @override   String getProfileData() => 'getProfileData mock'; }  class RestServiceImpl extends RestServiceMock {   const RestServiceImpl._();      factory RestServiceImpl() = _RestApiSplitedService;      final String name = 'Акакий';      void _getToken() => print('Here we get Token'); }  class _RestApiSplitedService extends RestServiceImpl with AuthPart, ProfilePart {    _RestApiSplitedService() : super._(); }  mixin AuthPart on RestServiceImpl {   @override   void logout() {     _getToken();     print('logout $name');   } }  mixin ProfilePart on RestServiceImpl {   @override   String getProfileData() => 'getProfileData: $name'; } 

Можно открыть в DartPad и поиграться!

Выводы

Разделение крупных классов на несколько файлов с помощью миксинов — это быстрое решение, которое помогает уменьшить конфликты при merge и упростить отслеживание истории изменений в Git для конкретных файлов.

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