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