我正在将其发布在lua和codea中，因为这是我正在使用的，但这是一个相当普遍的问题。
我正在考虑显示图形的总体设计模式，我想知道它是否存在问题。
这是我正在考虑的设计模式：
Main类中的setup()方法告诉Graphics类以创建一些图形元素：例如，两个正方形和一个椭圆形。
Graphics类生成每个元素所需的参数，将其存储为表，然后将表发送到Data类。
应用程序开始绘图时，Main中的draw()功能告诉Graphics类绘制创建的对象。
然后，Graphics类要求Data类移交给setup()期间发送的所有表，并使用它们来绘制元素。
Main命令Graphics命令和查询Data。我敢肯定这是一个已知的模式：通常存在问题吗？
您正在做的事情 - 本质上是模型视图控制器，通常用于行业和应用程序开发中。它的效果相对较好，尽管没有编程范式没有缺陷。话虽如此，MVC是为大型团队而设计的。从逻辑上来说，多个人不可能在一个Codea项目上共同努力，因此鉴于您是自己的工作，我猜该项目将是中等规模的。在这样的项目独奏时，务实的直观方法是迄今为止最好的选择。
在这样的事情上使用MVC有点像建立整个民主国家，包括国会/议会，国家元首和法院制度，只是为了管理一个家庭的行动。民主是良好的，并且强大的选举和制衡体系是保持系统顺利运行的唯一途径。但是，在家庭中，即使仍然需要维持秩序和幸福，方法也完全不同。
对您来说，您能做的最好的就是考虑思想在您的脑海中的结构。您是否认为敌人的ho积是一个实体，还是自主对象的集合？您是否认为飞船是属性的完美数学集合，或者用户在屏幕上与用户互动的图像？当出现暂停屏幕时，游戏屏幕仍然存在，只是隐藏了，还是停止了并已被替换？
此外，您如何构建想法？您是从广泛的类别开始，逐步研究了详细的细节，还是在努力为世界建立世界的脑海中有生动的心理形象？您对程序的概念是否包括一个庞大的流程图，该流程图在某些方面涉足现实，还是一系列节点互相发送信息？所有这些都是您可以回答的问题。如果您自然地倾向于MVC，则可能需要坚持下去。如果您在书中读到了有关它的信息，并决定，即使您并没有真正看到它有用的原因，它也必须是某种魔术小精灵尘埃您要重新考虑。
快乐编码！
顺便说一句，我认为这个问题比堆栈溢出更适合堆栈交换程序员。这是一个微妙的区别，但是堆栈溢出是针对 facts 的，例如bug-fixes和算法，而程序员则用于 cominions
Div>