Question

我正在为类图建模，我完全坚持这个问题：

我的新网络应用程序有“卡片”（关于某个主题的条目），可由用户修改，àlàwiki。但与维基不同，不同的卡持有不同的数据。与wiki不同，卡在数据库中明确地与其他卡相互关联。让我向您展示我最初是如何使用虚拟示例设计的：

/** 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子类不相关，原始设计就可以了。

请帮忙！

Answer 1

我会采用域驱动的方法。您的用户会称他们为“卡”吗？这似乎是一个技术问题，但您将技术问题（卡片）与域名问题（博物馆，绘画）混合在一起。

在不了解您的域名和用户的情况下，很难猜测您的最终解决方案是什么。

也许这就是：

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

class Card is composed of Set<Content>

通过这种方式，您可以将您的域模型（博物馆，绘画）与您的视图模型（卡片）分开。我甚至会更进一步，不使用继承（使用普通的java-object）路由，但我不知道你的确切实现。

如果您想了解有关此设计风格的更多信息，this podcast会很有帮助。

Answer 2

@迈克尔有一个好点。 博物馆是一个域对象，绘画也是如此。听起来你正在使用“卡片”来收集各种人对这些画作的评论。这表明你正在尝试建模 CardFile 。 CardFile 将是 Cards 的集合。 A Card提及相关的博物馆或绘画。

以下是一些提示：

写出一些用户故事或用例。你太早被程序员思考了;先考虑一下你想做什么。如果你没有最喜欢的方式，那么使用这个模型：“某人”“做某事”以获得一些结果。因此，例如，“为了找出哪个博物馆有它，我得到了关于Magritte'Ceçin'espas une pipe'的所有卡片。”
为类编写一些“用户代码”。伪代码很好，但它确实有助于提出界面。

所以你可以写：

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

我一点也不发誓，这是最好的方式，但只是一个例子。

如果这里的“版本控制”是有很多与同一幅画相关联的卡片，那么现在就设置了。如果卡上的格式，方法，数据项随着时间的推移而发生变化，那么您需要确定哪些特定于卡，并使其成为超类。然后你可以让卡的更新版本成为卡的新子类：保持相同的东西在超类中，不同的parfts是子类的业务。

在版本相关时建模版本控制

2 个答案: