MVC Объектно-ориентированный

Question

Я немного сбит с толку относительно ... ну, проще говоря ... как MVC полностью объектно-ориентирован?

Из работы с большим количеством java и c # я знаю, что ООП, что объекты имеют состояния и поведение.

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

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

-(void)moveBalloon:(CGPoint)destination

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

Может быть, я думаю об этом странным образом. Обычно я рассматриваю BalloonView как отдельный объект от BalloonModel, а контроллер как собственный объект.

Неужели мое мышление здесь совершенно неверно?

Также .. С точки зрения возможности повторного использования, если бы я хотел передать этот объект кому-то еще для использования в их приложении, я бы дал им BalloonView и BalloonModel., но у них не будет доступа ни к каким действиям, которые я уже реализовал как часть объекта Balloon, потому что они находятся в контроллере.

Answer 1

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

Суть программы - ее бизнес-логика. В вашем примере с шариками модель обязательно должна иметь метод moveBalloon:, если ваша программа должна делать перемещение шариков. Иными словами, код модели должен быть способен делать все, что нужно вашей программе. Он должен хранить состояние программы, обрабатывать данные и все остальное, связанное с внутренней работой программного обеспечения. Представления должны быть фактическими элементами пользовательского интерфейса (окна, кнопки, текстовые поля, графика и т. Д.). Обычно они должны быть «тупыми» (т.е. без встроенной бизнес-логики). Контроллеры должны обрабатывать внутреннюю работу вашего интерфейса.

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

Answer 2

MVC и ООП:

Различные части приложения MVC взаимодействуют через события (или сигналы, или сообщения). Актер (представление, модель или контроллер) может отправлять такое событие, а другой субъект слушает это событие. Это не ООП в том смысле, что один объект знает другой и вызывает методы через определенный интерфейс, и это вас беспокоит.

Однако использование MVC даже способствует лучшему дизайну ООП! Тогда давайте сделаем так, чтобы все ваши объекты размещали свои данные и действия самостоятельно. Какие соединения вам понадобятся, чтобы позволить им играть вместе. MVC позволяет ограничить необходимые соединения между объектами . Это один из принципов ООП. Другая особенность MVC заключается в инкапсуляции ответственности всего приложения. Чтобы не использовать MVC, необходимо, чтобы логика вашего приложения была распределена по всему коду, а это не то, что предлагает ООП. MVC позволяет инкапсулировать различные части приложения и, следовательно, является ООП для макроуровня приложения. И - мы придерживаемся принципов ООП - вы легко можете изменить контроллер или модель или представление и сделать их многоразовыми и расширяемыми: D

Answer 3

Вы частично правы. Распределяя воздушный шар по частям MVC, вы не можете легко передать вид, модель и контроллер. Тем не менее, не волнуйтесь, вы увидите, у вас все еще может быть многоразовый воздушный шар даже с MVC. Но вам нужно немного изменить свое мнение.

Вы разрабатываете свой воздушный шар для запуска в приложении MVC так же, как всегда. Дайте ему несколько сеттеров и геттеров и назовите его BalloonView. Воздушный шар содержит только те данные, которые ему даны с помощью этих сеттеров.

Затем вы решаете, какие данные необходимы для запуска аэростата. Может быть местоположение воздушного шара. Создайте BalloonModel и присвойте ему свойства местоположения. В вашем приложении MVC данные могут храниться на уровне модели. Другой пользователь вашего аэростата (другое приложение) может хранить данные прямо в основном классе или даже устанавливать статические данные при настройке объекта. От пользователя зависит, как он / она обрабатывает данные всплывающей подсказки.

Затем контроллер соединяет аэростат с приложением. Там может быть кнопка, которая запускает контроллер. Контроллер обращается к BalloonModel, обновляет его с новым местоположением. Изменение BalloonModel должно затем каким-то образом распространяться в BalloonView. Есть разные методы, как это можно сделать. Среды MVC обычно ожидают, что модель будет отправлять события, а посредник представления связывает это событие и конкретное представление. Поэтому для представления не обязательно нужно знать его модель. Но это может сделать. В нашем примере модель отправит событие UPDATE, посредник получит это событие и обновит свойства местоположения представления. Другой пользователь (приложение) может полностью исключить контроллер, подключив кнопку напрямую с позиционированием шара:

onclick: balloonView.x += 5;

Видите ли, даже если вы не передадите модель и контроллер, ваш balloonView все равно можно будет использовать повторно.

-

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

Разработчик компонента пользовательского интерфейса часто создает мини-архитектуру MVC только для определенного компонента. Модель, представление и контроллер находятся в одном каталоге и могут быть скомпилированы в двоичный файл (my_super_list_component.binary) и повторно использованы в других проектах.