总的来说：

Question

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

举一个例子，在一个大学项目中，我必须开发一个棋盘游戏“骑车票”的实现。在那里，我有一个名为AbstractCard的Card类，代表游戏中的卡片，由TrainCard和DestinationCard子类。 AbstractCard类看起来像这样：

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

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

Answer 1

在纯粹的OO术语中，你可以说卡片类可以合理地负责绘制自己。

但是，您几乎总是希望分离关注点导致MVC方法或类似方法，其中控制卡行为的逻辑和呈现视觉表示的代码一张卡片属于不同的类别。

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

Answer 2

总的来说：

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

之后，您可以更新图形，而不必冒险重写业务逻辑。

相反，在逻辑层和表示层之间提供智能接口，以便在它们之间建立流畅的接口。这应该具有组合它们的所有好处，而没有任何障碍。

Answer 3

没有严格的规则，你必须将业务逻辑从UI中分离出来。

问自己这些问题：

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

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

更多信息

在模型类中包含图形功能是否有益？

3 个答案:

总的来说：