1

私はクラス図をモデル化していますが、この問題に完全に悩まされています。

私の新しいWebアプリケーションには、ユーザーが変更できる「カード」（主題に関するエントリ）があります。しかし、ウィキとは異なり、カードが異なればデータも異なります。また、ウィキとは異なり、カードはデータベース内で明示的に他のカードと相互に関連しています。ダミーの例を使用して、最初にどのように設計したかを示します。

/** 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クラスはCardInfoVersionサブクラスへのORM参照で埋められます。それから私はこれを思いついた：

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

これもにおいがします。実際、バージョンが消えてから、これはすべて台無しになっています。また、管理者はカードに提案された変更を検証する必要があります。

私はこの問題を解決する方法を本当に知りません。注意：CardInfoVersionサブクラスが相互に関連していなければ、元の設計で問題ありません。

助けてください！

4

2 に答える 2

0

@マイケルには良い点があります。 Museumはドメイン オブジェクトであり、Paintingも同様です。「カード」を使って、絵に対するさまざまな人のコメントを集めているようですね。これは、CardFileがモデル化しようとしているものであることを示唆しています。CardFileはCardsのコレクションになります。カードには、関連する美術館または絵画への参照があります。

ここにいくつかのヒントがあります：

  • いくつかのユーザー ストーリーやユース ケースを書き出します。あなたはプログラマーの思考に早すぎます。まずやりたいことを考える。これを行うのに好きな方法がない場合は、次のモデルを使用してください。「誰かが」「何かをする」「何らかの結果を得る」。たとえば、「マグリットの『Ceçi n'es pas une pipe』に関するすべてのカードを入手して、どの美術館にあるのかを調べます。」

  • クラスの「ユーザーコード」を書きます。疑似コードは問題ありませんが、インターフェイスを考え出すのに非常に役立ちます。

したがって、次のように書くことができます。

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

これが最善の方法だと断言しているわけではありませんが、例です。

  • ここでの「バージョン管理」が、同じ絵画に関連付けられた多くのカードがあることである場合、これで設定は完了です。カードの形式、メソッド、データ項目が時間の経過とともに変化している場合は、カードに固有のものを特定し、それをスーパークラスにする必要があります。次に、Card の新しいバージョンを Card の新しいサブクラスにすることができます。同じままのものはスーパークラスにあり、さまざまな部分はサブクラスのビジネスです。
于 2009-04-11T19:36:17.753 に答える
0

私はドメイン駆動型のアプローチを取ります。ユーザーはそれらを「カード」と呼びますか? それは技術的な懸念のようですが、技術的な懸念 (カード) とドメインの懸念 (美術館、絵画) が混在しています。

ドメインとユーザーを知らなければ、最終的なソリューションがどうなるかを推測することは困難です。

おそらくこれ：

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

class Card is composed of Set<Content>

そうすれば、ドメイン モデル (美術館、絵画) とビュー モデル (カード) を分離できます。私はそれをさらに一歩進めて、継承（plain-old-java-objectを使用）ルートを使用しませんが、正確な実装はわかりません。

このスタイルのデザインについて詳しく知りたい場合は、このポッドキャストが役に立ちます。

于 2009-04-11T17:09:09.620 に答える