>>3446824

>MVC
>модель
>контроллер

Представился бакой, а такие умные слова знает. Завидую.

>>3446824
Most Valuable Contributor это короче,

>На примере калькулятора

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

>Где у него модель,

оперативка.

>где представление,

Дислпей.

>а где контроллер?

Все остальное.

>>3446838 Я думаю, под калькулятором он имел в виду calc.exe, а не девайс с солнечной батарейкой, продаваемый за 200 рублей в переходе метро.

>>3446838
А почему Сырна перед тобой говорила все наоборот?

>>3446838

> оперативка

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

Допустим, у тебя есть приложение - калькулятор. Смотри.
View - это GUI и все его компоненты. Кнопки, чекбоксы, текстфилды и так далее.
Model - это твоя модель - калькулятор, конструктор которой принимает на вход первое и второе число.
Теперь самое интересное. Controller - это связующее звено, шина, интерфейс между view и model. В контроллере ты задаешь все события и действия, производимые над моделью из представления. Например:

• При клике на кнопку создается объект с параметрами, указанными в view-компонентах.
• Вызов метода calculate этого объекта выдает тебе результат.
• Результат передается в третье поле.

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

Итак.
Представление - это отображаемый пользователю интерфейс. Причем предназначенный только для вывода информации.

Модель - это обрабатываемые алгоритмы вычислений.

А контролер это как бы интерфейс для ввода?

Бака верно все усвоила?

>>3446886
Контроллер - грубо говоря это обработчик событий, применимых к view-компонентам. Вот и всё.

>>3446879
>>3446891
Бака осознала ошибку

>>3446858
Не сам процессор, а его регистры. У самого простого калькулятора их всего два. Контроллером является АЛУ процессора.
Команда на процессор приходит с клавиатуры (представление), но не сама команда, а просто логический уровень, его надо еще распарсить в команду, этим тоже занимается процессор, так как мы рассматриваем китайский калькулятор на одном чипе лепешкой, у него там должен быть дешифратор, который возьмет логические уровни с клавиатуры и послать инструкцию на АЛУ. Это будет медиатор - прослойка между кодом представления, которая инкапсулирует гуй, прослушивая от него события нажатия кнопок, а контроллеру отправляет семантически значимые команды.
Один из регистров напрямую связан с экраном, который всегда отображает его содержимое. Если перейти на софтварную аналогию, то тут используется байндинг напрямую из модели, многие MVC-фреймворки его обеспечивают, это одна из полезнейших их фич.
А вот если у нас есть интерфейс с перемещаемыми окнами и настраиваемыми менюшками, и их состояние надо запоминать, то нам нужна еще и модель для представления, и в какую категорию ее отнести мне неясно.

Хм... А на пике ввод идет минуя View

>>3446941
Это логично. Каждый раз при первоначальном запуске объекта "представления" еще нет. Но вызов конструктора который вьюху сгенерирует уже вышел.

MVC-калькулятор:
Model:

• приватные переменные x, y; x - число на экране, y - число "в уме".
• методы: setX(val) - если новое значение, то диспатчит событие xChanged; getX(), getY() - геттеры, метод copyXtoY() - записывает значение x в y, диспатчит событие yChanged;

View:
- класс CalcView создает кнопки 0-9, сброс, +-*/=, по нажатию каждой диспатчит событие "нажата кнопка такая-то", так же содержит текстовое поле экрана.

• класс CalcViewMediator содержит обработчики событий предствления, в каждом событии просто вызывает соответствующую команду контроллера, например на onBtn9Pressed отсылает Controller.addNumber(9). Если у нас нет байндинга, то подписывается на события изменения модели, по ним обновляет текстовое поле в CalcView.

Controller:

• Содержит все нужные методы, которые изменяют модель.

Дальше самое интересное: всю работу делает феймворк. В главном классе декларативно описываются все зависимости, а он сам потом создает модель, представление CalcView, к нему новый экземпляр CalcViewMediator, в него кидает ссылки на CalcView и модель, создает контроллер, связывает сообщения представления с методами контроллера. В результате все это работает.
Плюсы этого подхода - любой функционал, который добавляется, именно добавляется, а не пришивается сбоку или вклинивается между существующим кодом.