Каков правильный дизайн системы при работе с сторонним API?

Это сообщение в блоге Джоубера только что открыло мне глаза. Я рассмотрел множество шаблонов проектирования на Java и других языках. Но Objective-C – довольно уникальный язык.

Предположим, что в проекте мы говорим с сторонним API, как Dropbox или Facebook. То, что я делал до сих пор, – это объединить все, что связано с сторонним API, в одноэлементный класс. Поэтому я могу получить доступ к классу из любого места в контроллерах моего представления. Я могу просто пойти, например: [[DropboxModel sharedInstance] uploadFile:aFile]

Однако, как отмечается в сообщении в блоге, это неэффективно и приводит к коду спагетти и плохому тестированию модулей. Итак, каков наилучший способ разработки системы, чтобы она была модульной и простой в использовании?

3 Solutions collect form web for “Каков правильный дизайн системы при работе с сторонним API?”

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

Мне нравится идея Джоубера о введении экземпляра singleton в контроллер (ы) из делегата приложения (который сам по себе является singleton, гм). Я думаю, что такой же подход будет работать для вас.

То, что я обычно делаю в таких ситуациях, когда я могу использовать другой объект-заглушку в модульных тестах, – это определить протокол для представления API и сделать его «реальным» объектом API соответствующим ему, а также моим объектом-заглушкой API. Я использую заглушку в модульных тестах и ​​реальный объект в приложении.

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

 #define DBM [DropboxModel sharedInstance] <...> [DBM uploadFile:aFile]; 

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

вы можете выставлять только то, что вам нужно и использовать, и добавлять свое собственное состояние, проверять и удобно обрабатывать все проблемы библиотеки с одного места. «проблемы» могут быть введены по нескольким причинам – это могут быть потоки, ресурсы, состояние или нежелательные поведенческие изменения в разных версиях.

большинство библиотек не предназначено для использования исключительно через одноэлементный. в таких случаях лучше (субъективно) создавать интерфейсы, как обычно, – конечно, помня о ограничениях, лежащих в основе уровня абстракции. в этом смысле вы просто создаете объектно-ориентированные интерфейсы, которые делятся на size / task / purpose / functions – все, что вы обычно делаете при написании собственных классов.

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

если вы используете библиотеку повсюду, то вы также можете использовать вызовы без слоя абстракции.

PhoneC: Разработка iOS проста с помощью XCode, Swift3, UITableView, cocatouch, давайте создадим приложения для iPhone, iPad и Macbook.