ого! а, тогда, какой смысл в контролле вообще?

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

Публичный для кого и для каких целей?

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

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

В таком случае я не лазил в модели через дочернние контролы, а просто менял строки из главного контрола, так как главная модель это модель главного контрола.

Правда пример плохой, в данной ситуации у меня скорее всего был бы только один контрол на всё это дерево моделей и вьюх. Что-то умнее щас не придумалось:)

Crazy, для других контроллеров, очевидно.

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

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

Откуда такой странный дизайн?

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

Это называется blob antipattern -- когда систему пронизывают хаотичные связи типа "захотел и взял публичные данные". И внесение изменений в одной части вызывает непредсказуемые эффекты по всей системе.

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

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

Это всё описание вот этой модели.

Отлично. Пусть знают, если это им нужно. Зачем, кстати?

Если у них уже есть нужные им данные -- зачем они лезут в чужую модель? Если в их модели нет нужных им данных -- ее неправильно спроектировали. Нужно исправить, пока не поздно.

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