Подходы к проектированию иерархии объектов - PullRequest
Новая
       21

Подходы к проектированию иерархии объектов

0 голосов
/ 26 января 2012

Я создаю приложение, которое сможет выводить данные в формате RSS, а также в более подробный пользовательский формат XML. У меня два противоречивых подхода к созданию иерархии объектов.

Вариант 1 - Постройте иерархию в соответствии с требованиями каждого формата (RSS / XML) 

FeedItem (RSS properties)
    title
    description
    link
^
|

DetailedFeedItem (Detailed XML properties)
    expirationDate
^
|

Article (Detailed XML Article-specific properties)
    paragraphs

Хотя это решение работает, создается впечатление, что объекты связаны с их визуальными требованиями (RSS / XML).

Вариант 2 - Построить иерархию на основе более общей абстракции: 

Item
    title
    description
    expirationDate

^
|

Article
    paragraphs

Этот подход кажется мне более гибким и простым, но тогда, когда я создаю RSS, у меня могут быть свойства, которые не будут заполнены (expirationDate, параграфы). Если я выберу вариант 2, я подумал о создании класса, такого как RSSMapper, который бы брал объект и отображал только необходимые свойства в формат RSS - например, RSSMapper.mapArticle (Article article).

Как вы думаете, что будет лучшим способом продвижения вперед?

1 Ответ

1 голос
/ 26 января 2012

Вы правы, выбрав вариант 2) (в основном это шаблон адаптера ).

Ваш доменный объект должен каким-то образом быть независимым от его использования.Использование класса преобразования (или адаптера) для преобразования модели в представление - лучший способ обеспечить инкапсуляцию и разделение ответственности.Таким образом, если вы хотите представить модель в другом третьем формате (например, HTML?), Вам просто нужно создать соответствующий адаптер без необходимости изменения какого-либо существующего кода.

...