Модуляризация кода с использованием фреймворков в iOS - PullRequest
0 голосов
/ 03 мая 2019

Пытается найти лучший способ модульной структуры iOS. Это касается разработки SDK на таких языках, как Localytics, Instabug, Crashlytics и т. Д. *

Проблема заключается в совместном использовании кода между двумя разрабатываемыми SDK. то есть, если A и B являются SDK, приложение-потребитель iOS будет использовать A и B отдельно, также A зависит от B.

Приложение-потребитель будет сбрасывать A и B, используя cocoapods. A и B создали подспецификации, и когда приложение добавляет модуль «A», и A, и B вытягиваются в рабочую область.

Как A, так и B имеют зависимость от сети, аналитики, ведения журнала, и только B дополнительно имеет зависимость от хранилища.

Одна из первоначальных разработанных архитектур заключалась в том, чтобы иметь платформу C, в которой будет размещаться код, связанный с сетями, аналитикой, ведением журналов и хранением, чтобы A и B могли упоминать C в качестве зависимости. Хотя это работает прилично, эта архитектура работает против принципа единой ответственности. Например: C содержит довольно много кода, и если фреймворк D хочет только хранилище, ему придется получить весь фреймворк C только для одного его компонента.

Вторым архитектурным замыслом было разделить инфраструктуру C на сети N, Analytics Y, Logging L и Storage S и создать систему на основе версий. Кроме того, A и B могут быть разделены на несколько небольших структур для поддержки принципов SOLID. Хотя это кажется небольшим бременем в плане обслуживания, я лично считаю, что это определенно правильный способ выполнения модульности независимо от стабильности модуля, существующей в Swift 5 или нет. Но одним из недостатков этой архитектуры является то, что когда приложение-потребитель добавляет модуль «A», все зависимости будут добавлены в приложение, и будут открыты открытые функции меньших платформ. Кроме того, если вы используете B внутри A и изменяется версия N, то и B, и A должны изменить версию N, поскольку две версии N не могут находиться вместе в одной кодовой базе.

Третий архитектурный проект состоял в том, чтобы иметь общий код между A и B. То есть A и B будут иметь внутри себя N, Y, L и S как классы, и они будут поставляться как две разные платформы. Недостатком этого является то, что если A использует B, а у A и B есть N, Y, L и S, то у нас будет дублирование кода, и SDK будут раздуваться.

Я знаю, что не существует идеального решения, просто пытаюсь получить некоторую информацию об этом аспекте модульности. Любая помощь очень ценится.

...