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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

#define DBM [DropboxModel sharedInstance]

<...>
[DBM uploadFile:aFile];