我正在爲一個Uni項目設計一個彈球遊戲，其中應該有兩種模式：運行模式和生成器模式，從而可以設計/重新設計機器的佈局。使用或不使用狀態模式？
我最初的想法是國家模式 - 但是，我擔心的是國家之間的共同接口可能會將它們收縮爲實施不適合該州的方法。
例如，在建造者模式下，設置保險槓的位置或任何東西都是完全合適的;但在運行模式下，它將被實現爲無所事事或拋出異常 - 這看起來很討厭，特別是如果有很多這樣的方法。
有沒有更好的設計呢？
你的直覺是正確的。當一個程序可以有許多不同的狀態時，狀態模式很有用，每個狀態支持許多相同的操作。例如，一個繪圖程序可能有許多不同的工具，但每個工具都支持類似的操作，比如放筆或放筆，並在兩點之間劃一條線。
在你的情況只有2個國家，他們不共享太多的行爲。他們分享的主要內容是常見的GUI操作，這些操作可能已經在標準庫中。您確實需要確保顯示緩衝區的代碼不會重複，但您可以在沒有狀態模式的情況下執行此操作。
幾年前，我在大學有一個類似的任務。
我會說使用狀態模式對於這一點是過度的，以及不完全適合，如前所述。我們所做的這個任務是：
基本上，正如其他地方提到的那樣，這兩種模式並沒有共同足夠的共性來真正證明這裏的狀態模式。
有一種應用狀態模式的可能性，這是有道理的。由於這是一項大學任務，因此背後的想法和理由可能值得讚揚。這與我之前提到的「高於上一級」有關。根據我的經驗，這是獨立於模式的GUI的一部分。它允許關閉應用程序，打開以前的彈球配置，以及在模式之間切換。它也可以做的是顯示上下文相關菜單項。菜單的狀態可以從當前模式中檢索。因此，構建器模式可以包括保存和其他構建器特定的操作，並且運行模式可以提供播放/暫停選項。如果你花時間研究了國家格局，並希望能夠得到回報，這將是一個可能的選擇。
P.S.Murray當時看起來對我們使用設計模式似乎很熱心;-)
你能解釋一下你的意思嗎？ – Robert 2010-01-28 00:02:59
我在考慮包含對兩種不同模式的引用的對象，並允許在它們之間切換的能力。這些模式不應該知道如何在他們自己之間切換，這是他們「之上」的責任。作爲一個具體的例子，如果每個模式都包含在一個JPanel中，那麼「上面的級別」就是JFrame中的兩個引用，並且有一個控件（如菜單項）在它們之間切換。這是否更有意義？ – Grundlefleck 2010-01-28 00:26:33
順便說一句：「以上級別」不是一個適當的技術術語（正如您可能已經猜到的那樣），所以它不是真正的Googleable。 「組成這兩個模式對象的對象」可能更接近正確的術語。 – Grundlefleck 2010-01-28 00:32:57
您需要使用模式嗎？兩個州並沒有證明這一點。 – ChaosPandion 2010-01-27 19:35:44
根本沒有，但高度分離得到更多的分數 – Robert 2010-01-27 19:39:07
我想到3個州，因爲它可能是好的，而不是在遊戲正在運行時切換到構建模式...... – Robert 2010-01-27 19:41:13