【问题标题】：Can it be beneficial to include graphics capabilities in model classes?在模型类中包含图形功能是否有益？
【发布时间】：2011-09-08 13:44:20
【问题描述】：

在 OO 设计中在其他模型类中包含绘图功能是否有益？

举个例子，在一个大学项目中，我必须开发一个棋盘游戏“ticket to ride”的实现。在那里，我有一个名为 AbstractCard 的 Card 类，用于表示游戏中的一张卡片，它是 TrainCard 和 DestinationCard 的子类。 AbstractCard 类看起来像这样：

-------------------------------
|      AbstractCard            |
-------------------------------
|                              |
--------------------------------
|drawFront(Graphics2D:g2):void |
|drawBack(Graphics2D:g2):void  |
--------------------------------

子类添加额外的数据和方法。

【问题讨论】：

标签： oop graphics

【解决方案1】：

您必须将业务逻辑与 UI 分开并没有硬性规定。

问自己这些问题：

您正在设计的类将来被修改的概率是多少？
以后会不会增加其他的用户界面（视图）（比如通过Web服务访问业务逻辑等）？

在大多数情况下，上述问题的答案是响亮的是。但请注意，当您实现这种松散耦合时，会对应用程序的性能产生负面影响 (Designing Too Far Into The Future)。所以我的建议是，除非应用程序需要松散耦合，否则不要这样做。当心overengineering！

更多信息

【讨论】：

【解决方案2】：

一般：

不，这将成为以后的障碍。尝试将您的演示文稿（绘图/布局）与您的逻辑（模型）分开。

这样以后您就可以修改图形，而不必冒险重写您的业务逻辑。

相反，在逻辑层和表示层之间提供智能接口，以便在它们之间拥有流畅的接口。这应该可以毫无阻碍地结合它们的所有好处。

【讨论】：

【解决方案3】：

在纯粹的 OO 术语中，您可以争辩说 Card 类可以合理地负责绘制自己。

但是，您几乎总是需要关注点分离，这会导致MVC 方法或类似方法，其中控制卡片行为方式的逻辑和用于呈现卡片视觉表示的代码属于不同的班级。

这种方法有几个优点，包括（但不限于）每个类都具有更高的内聚性，因为它没有多重职责，并且更容易单独测试模型类只包含纯业务逻辑。

【讨论】：