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

Во-первых. Я согласен с предыдущими ответами, в которых основное внимание уделяется важности размещения данных в объектах модели, когда это необходимо (в соответствии с шаблоном проектирования MVC). Обычно вы не хотите помещать информацию о состоянии внутрь контроллера, если только это не строго «презентационные» данные.

Во-вторых, см. стр. 10 презентации Стэнфордского университета, где показан пример того, как программно установить контроллер на контроллер навигации. Пример того, как сделать это «визуально» с помощью Interface Builder, можно найти на странице это руководство.

В-третьих и, возможно, самое главное, обратите внимание, что «лучшие практики», упомянутые в презентации Стэнфорда, намного легче понять, если вы подумаете о них в контексте «зависимости инъекция "шаблон проектирования. Вкратце, это означает, что ваш контроллер не должен «искать» объекты, которые ему нужны для выполнения своей работы (например, ссылаться на глобальную переменную). Вместо этого вы всегда должны «вводить» эти зависимости в контроллер (т. Е. Передавать необходимые ему объекты через методы).

Если вы будете следовать шаблону внедрения зависимостей, ваш контроллер будет модульным и многоразовым. И если вы задумаетесь о том, откуда берутся докладчики из Стэнфордского университета (т.е. как сотрудники Apple, их работа заключается в создании классов, которые можно легко использовать повторно), возможность повторного использования и модульность являются первоочередными задачами. Все упомянутые передовые методы обмена данными являются частью внедрения зависимостей.

В этом суть моего ответа. Я приведу ниже пример использования шаблона внедрения зависимостей с контроллером, если это будет полезно.

Пример использования внедрения зависимостей с контроллером представления

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

Чтобы создать это, вы можете создать класс BookPickerViewController, который контролирует и отображает объекты графического интерфейса / представления. Где взять все данные о книгах? Допустим, это зависит от объекта BookWarehouse. Итак, теперь ваш контроллер в основном передает данные между объектом модели (BookWarehouse) и объектами графического интерфейса / представления. Другими словами, BookPickerViewController ЗАВИСИТ от объекта BookWarehouse.

Не делайте этого:

@implementation BookPickerViewController

-(void) doSomething {
   // I need to do something with the BookWarehouse so I'm going to look it up
   // using the BookWarehouse class method (comparable to a global variable)
   BookWarehouse *warehouse = [BookWarehouse getSingleton];
   ...
}

Вместо этого зависимости должны быть введены следующим образом:

@implementation BookPickerViewController

-(void) initWithWarehouse: (BookWarehouse*)warehouse {
   // myBookWarehouse is an instance variable
   myBookWarehouse = warehouse;
   [myBookWarehouse retain];
}

-(void) doSomething {
   // I need to do something with the BookWarehouse object which was 
   // injected for me
   [myBookWarehouse listBooks];
   ...
}

Когда ребята из Apple говорят об использовании шаблона делегирования для «обратной связи по иерархии», они все еще говорят о внедрении зависимостей. В этом примере, что должен делать BookPickerViewController, когда пользователь выбрал свои книги и готов их оформить? Что ж, это не совсем его работа. Он должен ДЕЛЕГИРОВАТЬ эту работу с каким-то другим объектом, что означает, что это ЗАВИСИТ от другого объекта. Итак, мы можем изменить наш метод инициализации BookPickerViewController следующим образом:

@implementation BookPickerViewController

-(void) initWithWarehouse:    (BookWarehouse*)warehouse 
        andCheckoutController:(CheckoutController*)checkoutController 
{
   myBookWarehouse = warehouse;
   myCheckoutController = checkoutController;
}

-(void) handleCheckout {
   // We've collected the user's book picks in a "bookPicks" variable
   [myCheckoutController handleCheckout: bookPicks];
   ...
}

Конечным результатом всего этого является то, что вы можете предоставить мне свой класс BookPickerViewController (и связанные объекты GUI / представления), и я могу легко использовать его в своем собственном приложении, предполагая, что BookWarehouse и CheckoutController являются универсальными интерфейсами (то есть протоколами), которые я могу реализовать. :

@interface MyBookWarehouse : NSObject <BookWarehouse> { ... } @end
@implementation MyBookWarehouse { ... } @end

@interface MyCheckoutController : NSObject <CheckoutController> { ... } @end
@implementation MyCheckoutController { ... } @end

...

-(void) applicationDidFinishLoading {
   MyBookWarehouse *myWarehouse = [[MyBookWarehouse alloc]init];
   MyCheckoutController *myCheckout = [[MyCheckoutController alloc]init];

   BookPickerViewController *bookPicker = [[BookPickerViewController alloc] 
                                         initWithWarehouse:myWarehouse 
                                         andCheckoutController:myCheckout];
   ...
   [window addSubview:[bookPicker view]];
   [window makeKeyAndVisible];
}

Наконец, ваш BookPickerController не только многоразовый, но и его легче тестировать.

-(void) testBookPickerController {
   MockBookWarehouse *myWarehouse = [[MockBookWarehouse alloc]init];
   MockCheckoutController *myCheckout = [[MockCheckoutController alloc]init];

   BookPickerViewController *bookPicker = [[BookPickerViewController alloc] initWithWarehouse:myWarehouse andCheckoutController:myCheckout];
   ...
   [bookPicker handleCheckout];

   // Do stuff to verify that BookPickerViewController correctly called
   // MockCheckoutController's handleCheckout: method and passed it a valid
   // list of books
   ...
}

Такие вещи всегда дело вкуса.

Сказав это, я всегда предпочитаю осуществлять координацию (№2) через объекты модели. Контроллер представления верхнего уровня загружает или создает необходимые ему модели, и каждый контроллер представления устанавливает свойства в своих дочерних контроллерах, чтобы сообщить им, с какими объектами модели им нужно работать. Большинство изменений передаются вверх по иерархии с помощью NSNotificationCenter; запуск уведомлений обычно встроен в саму модель.

Например, предположим, что у меня есть приложение с учетными записями и транзакциями. У меня также есть AccountListController, AccountController (который отображает сводку учетной записи с кнопкой «показать все транзакции»), TransactionListController и TransactionController. AccountListController загружает список всех учетных записей и отображает их. Когда вы нажимаете на элемент списка, он устанавливает свойство .account своего AccountController и помещает AccountController в стек. Когда вы нажимаете кнопку «показать все транзакции», AccountController загружает список транзакций, помещает его в свойство TransactionListController .transactions, помещает TransactionListController в стек и так далее.

Если, скажем, TransactionController редактирует транзакцию, он вносит изменения в свой объект транзакции, а затем вызывает свой метод save. 'save' отправляет TransactionChangedNotification. Любой другой контроллер, которому необходимо обновить себя при изменении транзакции, будет отслеживать уведомление и обновляться. TransactionListController предположительно будет; AccountController и AccountListController могут, в зависимости от того, что они пытались сделать.

Для №1 в моих ранних приложениях у меня был какой-то метод displayModel: withNavigationController: в дочернем контроллере, который настраивал и помещал контроллер в стек. Но когда мне стало удобнее работать с SDK, я отошел от этого, и теперь я обычно заставляю родителя подталкивать ребенка.

Для № 3 рассмотрим этот пример. Здесь мы используем два контроллера, AmountEditor и TextEditor, для редактирования двух свойств транзакции. Редакторы не должны фактически сохранять редактируемую транзакцию, поскольку пользователь может решить отказаться от транзакции. Поэтому вместо этого они оба берут свой родительский контроллер в качестве делегата и вызывают на нем метод, сообщая, изменили ли они что-нибудь.

@class Editor;
@protocol EditorDelegate
// called when you're finished.  updated = YES for 'save' button, NO for 'cancel'
- (void)editor:(Editor*)editor finishedEditingModel:(id)model updated:(BOOL)updated;  
@end

// this is an abstract class
@interface Editor : UIViewController {
    id model;
    id <EditorDelegate> delegate;
}
@property (retain) Model * model;
@property (assign) id <EditorDelegate> delegate;

...define methods here...
@end

@interface AmountEditor : Editor
...define interface here...
@end

@interface TextEditor : Editor
...define interface here...
@end

// TransactionController shows the transaction's details in a table view
@interface TransactionController : UITableViewController <EditorDelegate> {
    AmountEditor * amountEditor;
    TextEditor * textEditor;
    Transaction * transaction;
}
...properties and methods here...
@end

А теперь несколько методов из TransactionController:

- (void)viewDidLoad {
    amountEditor.delegate = self;
    textEditor.delegate = self;
}

- (void)editAmount {
    amountEditor.model = self.transaction;
    [self.navigationController pushViewController:amountEditor animated:YES];
}

- (void)editNote {
    textEditor.model = self.transaction;
    [self.navigationController pushViewController:textEditor animated:YES];
}

- (void)editor:(Editor*)editor finishedEditingModel:(id)model updated:(BOOL)updated {
    if(updated) {
        [self.tableView reloadData];
    }

    [self.navigationController popViewControllerAnimated:YES];
}

Следует отметить, что мы определили общий протокол, который редакторы могут использовать для связи со своим контроллером. Таким образом, мы можем повторно использовать редакторов в другой части приложения. (Возможно, в учетных записях тоже могут быть заметки.) Конечно, протокол EditorDelegate может содержать более одного метода; в данном случае это единственное, что необходимо.

Я вижу твою проблему ..

Случилось так, что кто-то запутал представление об архитектуре MVC.

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

так что ... вы не хотите иметь несколько контроллеров представления ..

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

взгляды НЕ должны быть основанием для принятия решений. Контроллер (ы) должен это делать. Отсюда разделение задач, логики и способов облегчить вашу жизнь.

Итак ... убедитесь, что ваше представление именно это делает, выдает хороший вид данных. пусть ваш контроллер сам решает, что делать с данными и какое представление использовать.

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

Предположим, есть два класса A и B.

экземпляр класса A

A aInstance;

класс A создает и экземпляр класса B, как

B bInstance;

И в вашей логике класса B где-то вы должны сообщать или запускать метод класса A.

1) Неправильно

Вы можете передать aInstance в bInstance. теперь поместите вызов желаемого метода [aInstance methodname] из желаемого места в bInstance.

Это послужило бы вашей цели, но освобождение привело бы к блокировке, а не освобождению памяти.

Как?

Когда вы передали aInstance в bInstance, мы увеличили удержание aInstance на 1. При освобождении bInstance мы заблокируем память, потому что aInstance никогда не может быть доведен до 0 keepcount с помощью bInstance, потому что сам bInstance является объектом aInstance.

Кроме того, из-за зависания aInstance память bInstance также будет заблокирована (утечка). Таким образом, даже после освобождения самого aInstance, когда его время придет позже, его память также будет заблокирована, потому что bInstance не может быть освобожден, а bInstance является переменной класса aInstance.

2) Верно

Определив aInstance в качестве делегата bInstance, не будет никаких изменений сохраненного счета или запутывания памяти для aInstance.

bInstance сможет свободно вызывать методы делегата, лежащие в aInstance. При освобождении bInstance все переменные будут созданы самостоятельно и будут освобождены. При освобождении объекта aInstance, поскольку в bInstance нет запутывания aInstance, он будет освобожден чисто.