我在Lua和Codea上发布这个，因为我正在使用它，但我认为这是一个非常普遍的问题。
我正在考虑用于显示图形的整体设计模式，我想知道它是否存在问题。
这是我正在考虑的设计模式：
setup()类中的Main方法告诉Graphics类创建一些图形元素：例如，两个正方形和一个椭圆。
Graphics类生成每个元素所需的参数，将它们存储为表，并将表发送到Data类。
当应用程序开始绘制时，draw()中的Main函数会告诉Graphics类绘制已创建的对象。
然后Graphics类要求Data类传回它在setup()期间发送过的所有表格，并使用它们绘制元素。
Main命令Graphics命令和查询Data。我确信这是一个已知的模式：通常与它有关的问题吗？
答案 0 :(得分：3)
您正在做的事情 - 基本上是模型 - 视图 - 控制器，通常用于工业和应用程序开发。虽然没有编程范式没有缺陷，但它的工作相对较好。话虽这么说，MVC是为大型项目团队而设计的。从逻辑上来说，多个人在一个Codea项目上一起工作是不可能的，所以考虑到你自己工作，我猜这个项目将是中小规模的。在这样的项目上独立工作时，务实，直观的方法是目前最好的选择。
在这样的事情上使用MVC有点像建立一个完整的民主国家，完成一个国会/议会，国家元首和法院系统，只是为了管理一个家庭的事情。民主是好的，强大的选举和制衡制度是保持系统顺利运行的唯一途径。然而，在一个家庭中，即使仍然需要保持秩序和幸福，这种方法是完全不同的。
对你而言，你能做的最好的事情就是思考你的思想是如何构建的。你认为敌人是一个单一的实体，还是一个自治对象的集合？您是否认为宇宙飞船是一个完美的数学属性集合，或者是用户在屏幕上与之交互的图像？当暂停屏幕出现时，游戏画面是否仍然存在，只是隐藏，还是已经不存在并被替换？
而且，你如何构建想法？你是从广泛的类别开始，深入到更精细的细节，还是在你的头脑中有一个生动的心理形象，你努力建立一个世界？您的程序概念是否包含一个庞大的流程图，该流程图在某些点沉入现实，或者是一组节点彼此发送消息？所有这些都只是你能回答的问题。如果你自然而然地倾向于MVC，你可能会想要坚持下去。如果你在一本书中读到它，并决定，即使你没有真正理解为什么它有用，它必须是某种神奇的小精灵粉尘你可以洒在任何项目上，以使它变得容易，我敦促你要重新考虑。
快乐的编码！
顺便说一句，我认为这个问题比堆栈溢出更适合Stack-Exchange programmers。这是一个微妙的区别，但Stack Overflow用于事实，如错误修复和算法，而程序员则用于意见如何编写软件。