這種設計模式是否存在問題：Main - > Graphics <--> Data？

Question

我在Lua和Codea發佈這個，因爲這就是我使用的，但這是一個非常普遍的問題，我認爲。

我正在考慮顯示圖形的整體設計模式，我想知道它是否有問題。

這裏是我考慮的設計模式：

在Main類A setup()方法告訴Graphics類來創建一些圖形元素：例如，兩個正方形和一個橢圓。

Graphics類生成每個元素所需的參數，將它們存儲爲一個表，然後將該表發送到一個Data類。

當應用程序開始繪製時，Main中的draw()函數告訴Graphics類繪製已創建的對象。

然後Graphics類要求Data類將setup()期間發送的所有表交回，並使用它們繪製元素。

Main命令Graphics哪些命令和查詢Data。我確信這是一個已知的模式：通常與它有關的問題嗎？

Answer 1

你在做什麼 - 這實質上是模型視圖控制器，通常用於工業和應用程序開發。它工作得比較好，儘管沒有編程範例沒有缺點。這就是說，MVC是專門爲大型團隊工作的大型項目。多個人在一個單一的Codea項目上一起工作是不可能的，所以假設你正在自己工作，我猜這個項目將會是小到中等規模。在單獨工作這樣的項目時，務實，直觀的方法是迄今爲止最好的選擇。

在這樣的事情上使用MVC有點像建立一個完整的民主體制，有一個議會/議會，國家元首和法院系統來管理單個家庭的事情。民主是好的，強大的選舉和制衡機制是保持體系平穩運行的唯一途徑。然而，在家庭中，儘管仍然需要保持秩序和幸福，但這種方法完全不同。

對於你來說，你所能做的最好的事情就是想想你的思維是如何構成的。你是否將一堆敵人看作是一個單一的實體，或者將它們看作一個自治對象的集合？你認爲宇宙飛船是一個完美的數學屬性集合，或者用戶在屏幕上交互的圖像？當暫停屏幕出現時，遊戲屏幕是否仍然存在，是否隱藏，或已不存在並被替換？

此外，您如何構思創意？你是從廣泛的範疇入手，深入細緻地研究細節，還是在腦海中形成一種生動的心智形象，以致力於建立一個世界？您的程序概念是否包含一個在某些點處陷入現實的巨大流程圖，或者是一組節點將消息發送給另一個節點？所有這些只是你可以回答的問題。如果你自然傾向於MVC，你可能想要堅持下去。如果你在一本書中讀到它，並決定，即使你不明白爲什麼它有用，它肯定是某種魔法小精靈，你可以把它放在任何項目上讓它變得簡單，我會敦促你要重新考慮。

快樂編碼！

順便說一句，我認爲這個問題比堆棧溢出更適合Stack-Exchange programmers。這是一個微妙的區別，但堆棧溢出是爲事實，如錯誤修復和算法，程序員是意見如何編寫軟件。