Давайте рассмотрим упрощенную архитектуру MVC, где Model работает с различными типами кондитерских изделий.Существуют различные подтипы класса Confection
, такие как Candy
, Cookie
, Doughnut
и т. Д. Каждый подтип, в свою очередь, имеет различные наборы свойств, например size
, color
, shape
и т. д.
Например, это одна реализация класса Candy
:
class Candy extends Confections {
public enum Size {
LARGE,
MEDIUM,
SMALL,
}
public enum Color {
RED,
GREEN,
YELLOW,
}
private Size size;
private Color color;
...
}
Теперь Модель хочет обновить представление с новым набором конфет для отображения.Допустим, единственное, что View нужно для получения изображения Confection
, - это строковое представление его типа и свойств, например, "candy_red_large"
.Самая глупая вещь для этого - иметь несколько instanceof
ветвей и switch
es для типов внутри View:
if (confection instanceof Candy) {
result.append("candy");
switch ((Candy) (confection).color) {
case RED:
result.append("_red");
break;
...
}
...
} else ...
Кроме того, этот монстр большой и уродливый, он также не приносит пользыот инкапсуляции и ООП.Давайте рассмотрим лучший способ сделать это, предоставив каждому подклассу Confection
метод, подобный toString()
, который будет возвращать желаемое строковое представление:
class Candy extends Confections {
...
public String toString() {
return ("candy_" + size + "_" + color).toLowerCase();
}
}
Единственная проблема, которую я вижу в этом подходе, это некоторыесвоего рода архитектурный «компромисс», когда Model фактически осведомлен о деталях реализации View, имеющих метод toString
, который бесполезен с точки зрения Model.
Какой наилучший подход или шаблоны проектирования использовать втакой случай для отображения разнородных данных из представления Model to View?