Моделирование версий, когда версии связаны - PullRequest
Новая
       14

Моделирование версий, когда версии связаны

1 голос
/ 11 апреля 2009

Я моделирую диаграмму классов и абсолютно застрял в этой проблеме:

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

/** Similar to strategy/bridge pattern */
class Card<T extends CardInfoVersion> is composed of T // container of versions
class CardInfoVersion // one version
class Painting extends CardInfoVersion 
class Museum extends CardInfoVersion is composed of Paintings

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

class Card<T extends CardInfoVersion> is composed of T
class CardInfoVersion
class Painting extends CardInfoVersion
class Museum extends CardInfoVersion is composed of Card<Painting>

Этот подход пахнет. Иерархия классов в CardInfoVersion огромна, поэтому модель UML будет нечитаемой, а класс Card будет заполнен ссылками ORM на подклассы CardInfoVersion. Тогда я придумал это: 

class Card is composed of proposedModifications: Set<Card>
class Painting extends Card
class Museum extends Card is composed of Paintings

Который также пахнет. На самом деле, это все запутано, так как версия исчезает. Это также требует от администраторов проверять предложенные модификации карт.

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

Пожалуйста, помогите!

Ответы [ 2 ]

0 голосов
/ 11 апреля 2009

@ У Майкла есть хорошая точка зрения. Музей является доменным объектом, как и Живопись . Похоже, вы используете «открытки» для сбора комментариев разных людей о картинах. Это говорит о том, что CardFile - это то, что вы пытаетесь смоделировать. CardFile будет набором карт . Карта имеет ссылку на соответствующий музей или картину.

Вот несколько подсказок:

  • написать несколько пользовательских историй или вариантов использования. Вы слишком рано погружаетесь в мысли программиста; сначала подумайте о том, что вы хотите сделать. Если у вас нет любимого способа сделать это, то используйте эту модель: «Кто-то» «что-то делает», «чтобы получить какой-то результат». Так, например, «я получаю все карточки о Магрите« Ceçi n'es pas une pipe », чтобы узнать, в каком музее она есть».

  • написать некоторый «код пользователя» для классов. Псевдокод в порядке, но он действительно помогает придумать интерфейс.

Так что вы можете написать: 

cards := cardfile.getAllCards(ceciNesPas)
for each card in cards
do
    print card.getPainting().getMuseum()
od

Я совсем не клянусь, что это лучший способ, но иллюстрация.

  • Если «версиями» здесь является то, что существует много карт, связанных с одной и той же картиной, теперь вы настроены. Если формат, методы, элементы данных на карточках со временем меняются, вам необходимо определить, что конкретно относится к карточке, и сделать ее суперклассом. Затем вы можете сделать более поздние версии карточек новыми подклассами карточек: то, что остается неизменным, относится к суперклассу, то переменные участки - это дело подкласса.
0 голосов
/ 11 апреля 2009

Я бы выбрал доменный подход. Ваш пользователь назвал бы их "картами"? Это, кажется, техническая проблема, но вы смешиваете свою техническую проблему (карты) с проблемами домена (музеи, картины).

Не зная вашего домена и пользователей, трудно угадать, каким будет ваше окончательное решение.

Возможно, это: 

class Museum extends Content is composed of Paintings
class Painting extends Content

class Card is composed of Set<Content>

Таким образом, вы разделяете модель вашего домена (Музей, Живопись) и модель представления (Карты). Я бы даже сделал еще один шаг вперед и не использовал бы маршрут наследования (идти с обычным-старым-java-объектом), но я не знаю вашей точной реализации.

Если вам нужна дополнительная информация об этом стиле дизайна, этот подкаст полезен.

...