-1

我倾向于有一个类来描述一般概念和子类来描述该概念中的差异。例如，Polygon<|-- { Rectangle、Triangle等}。

但是，我经常发现我对这些层次结构有各种表示。例如，我想将图形表示（例如，QPolygon）或物理表示（质量、centerOfMass）等与我拥有的另一个表示分开。

在我的例子中，我有一个纯数据对象的层次结构（ < | Command-- { WaitCommand, ,UnknownCommand等WaitCommandPanelUnknownCommandPanel

我的问题是，一旦我构建了数据表示，我就需要从数据飞跃到 GUI。

给定一个数据对象列表，我希望能够构造相应的 GUI 元素，但将两种表示分开。

一个 [糟糕] 的解决方案是让每个Command人都有能力（即，Command::getPanel()）返回其 GUI 表示。我不喜欢这样，因为我的数据类现在有表示代码。

另一个解决方案（我暂时采用）是进行查找。也就是说，当启动 GUI 时，给定一个Commands 列表（泛化），该函数根据其特殊类型确定要创建的对象。我也不喜欢这个。

有什么建议么？

4

2 回答 2

0

恕我直言，数据类和渲染类都没有责任决定将哪个渲染器用于给定的数据对象。我更喜欢你的第二个选择。我通常使用将数据类型映射到渲染器类的映射。另请注意，此类映射是特定于上下文的（Web 渲染将使用来自 destop 应用程序或健身上下文的不同渲染器）。

这种映射可以自动构建，例如使用属性（在 .Net 中）或命名约定（在 Lua 中）。或使用外部 XML-config 文件。

总结：必须有人做出决定，根据 SRP，渲染器和数据对象都不应为此负责。这种逻辑是特定于应用程序上下文的，因此应该“高于”这两个参与者（即渲染器和数据）。

于 2010-07-08T20:52:28.367 回答
0

您可能希望研究使用控制反转 (IoC) 容器来构建您的类。

每个类都将包含其关联类的接口。然后，IoC 容器会根据您的配置方式将该类的实现注入到您的对象中。

于 2010-07-08T20:57:15.373 回答