Шаблон для полиморфных видов

Question

Представьте, что у меня есть абстрактная модель "FriendEvent", которая имеет несколько разных конкретных реализаций, т.е. FriendPosted, FriendCommented, FriendUploadedPhoto и т. Д. Все они должны отображаться в моем представлении FriendEvents, но должны визуально отличаться друг от друга (например, FriendUploadPhoto должен содержать эскиз).

Что такое хороший объектно-ориентированный шаблон для достижения этой цели?

Мне интересно узнать, есть ли альтернатива включению конкретного класса модели в коде представления. Это почему-то кажется неправильным, потому что в нем используется условная логика, в которой, как я полагаю, можно полагаться на полиморфизм, но мне трудно придумать лучшую идею. Существуют ли какие-либо закономерности для решения этой проблемы?

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

Чтобы уточнить: как моделировать различные типы событий на уровне модели, это не проблема. Существует несколько хорошо известных ОО-решений. Вопрос касается кода представления, который отвечает за визуальное представление моделей. Я предполагаю, что у меня есть класс EventView, который имеет дело с отображением события (модели). Вопрос в том, как реализовать этот класс без блока переключателей, который выбирает другой путь к коду в зависимости от конкретного типа события.

Answer 1

Похоже, у вас есть некоторые DoubleDispatch проблемы, происходящие здесь.

Если я вас правильно понимаю, вы пытаетесь избежать смешения Model и View.Каждый класс Event может иметь

HtmlString getHtmlView() { /* code */ }

, но тогда все события имеют знание представления, и каждый раз, когда мы добавляем новый вид представления, мы добавляем новый метод getXXXView ().Я согласен, что это кажется неприятным.

Таким образом, мы могли бы увеличить разделение интересов, предложив всем событиям

HtmlViewMaker getHtmlMaker {  return new MyKindOfViwer(this); }

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

Однако у нас все еще есть проблема: каждому новому виду View нужен новый метод getXxxMaker.Итак, мы начинаем рассматривать более сложные фабрики, использование шаблонов и шаблонов и т. Д.

Answer 2

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