Объективный-c совет дизайна для использования различных источников данных, подкачивающих между тестом и живой

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

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

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

Таким образом, вопрос: что является лучшей практикой для создания тестовых репозиториев и классов, реализовывая их, и не имея необходимость зависеть от изменения нескольких мест в коде для свопинга между тестовыми классами и фактическими репозиториями / надлежащие вызовы API.

Рассмотрите следующий сценарий:

GetDataFromApiCommand *getDataCommand = [[GetDataFromApiCommand alloc]init];
getDataCommand.delegate = self;
[getDataCommand getData];

После того как данные доступны через API, "GetDataFromApiCommand" мог использовать фактический API, но до тех пор ряд ложных данных мог быть возвращен на вызов [getDataCommand getData]

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

На языках со строгим контролем типов мы могли использовать внедрение зависимости и просто изменить одно место. В цели-c мог быть реализован шаблон "фабрика", но это - оптимальный маршрут для движения для этого?

GetDataFromApiCommand *getDataCommand = [GetDataFromApiCommandFactory buildGetDataFromApiCommand];
getDataCommand.delegate = self;
[getDataCommand getData];

Что лучшие практики должен достигнуть этого результата?

Так как это было бы самым полезным, даже если бы Вы имеете фактический API в наличии, для запущения тестов или работы офлайн, ApiCommands должен был бы не обязательно быть заменен постоянно, но опция выбрать "Делают я хочу использовать TestApiCommand или ApiCommand".

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

ОТРЕДАКТИРУЙТЕ путь, которым я принял решение пойти с этим, должен использовать шаблон "фабрика".

Я настроил фабрику следующим образом:

@implementation ApiCommandFactory
+ (ApiCommand *)newApiCommand
{
    // return [[ApiCommand alloc]init];
    return [[ApiCommandMock alloc]init];
}
@end

И где угодно я хочу использовать класс ApiCommand:

GetDataFromApiCommand *getDataCommand = [ApiCommandFactory newApiCommand];

Когда фактический вызов API требуется, комментарии могут быть удалены, и насмешка может быть прокомментирована.

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

Если дополнительные параметры требуются, фабрика должна принять их во внимание т.е.:

[ApiCommandFactory newSecondApiCommand:@"param1"];

Это будет работать вполне хорошо с репозиториями также.