設計問題/應用結構和問題分離

Question

所以這個問題是從這裏（how to deal with multiple event args）的一種跟隨。這個問題引導我思考這個問題，但是有足夠的差異來證明自己的觀點。

我正在創建一個遊戲（用於娛樂和學習的目的），並想知道我是否使用了很好的設計標準。我想我可能已經在關注問題上進行了OTT，或者只是把事情弄錯了，但我希望事實並非如此。我沒有問題，因爲我想學習「最佳實踐」及其實際應用。

編輯

讓我解釋一下關於遊戲，它是基於碎石機上很多手機（quick demo found here）發現了一個遊戲。目標是選擇分組中的球來將他們從比賽中移除並獲得儘可能多的分數。

我想擴大一點，有不同類型的棋盤，球以不同的方式移動，以及不同的球類型，球可能會在他們被告知的地方，或者他們可能會沿途做一些事情。

因此，這裏是我所創建的對象的結構，最上面一行顯示了DLL與他們的對象，第二行顯示了這些對象的引用：

alt text http://lh3.ggpht.com/_eoaz2oX5m6U/SypiyjHGQoI/AAAAAAAAAUo/2geWlqNHqbs/structure.jpg

這是我在做UML嘗試：

alt text http://yuml.me/3279d2ac

Click here to link to full page for UML, makes it a little larger and hopefully easier to read

對象DLL包含在遊戲中使用的基本對象，球和棋盤。它們不包含任何關於它們如何對情況採取行動/反應的邏輯（球執行CompareTo和Equals方法）。可能有X個IBall的實現（IBoard也是如此，儘管我不會想象那麼多）。

InstanceManager DLL用作創建對象的一種方式，不確定這是否是100％需要它可能已經在對象DLL中。工廠是具有各種重載方法來創建IBall對象的靜態類。 BallFactory可以採用BallType Enum，Drawing.Color對象等。BoardFactory非常相似。 Jawbreaker是一個單例對象，處理諸如持有隨機對象（Random Object）這樣的事情，因爲它經常使用，還有一些GameConfiguration數據（與本主題不太相關）。

引擎DLL是大部分工作發生的地方。 LogicFactories採用BallType和BoardType對象來創建相關的邏輯對象。邏輯對象用於控制IBall和IBoard對象的工作方式。 BallLogic告訴球在事件發生時它可以做什麼。例如，當選擇一個Ball時，Ball Logic會調用一個方法來說明Y板上的Ball X已被選中。球可以做任何類型的球應該/可以做的事情。 BoardLogic非常相似，涉及董事會的行爲。

引擎對象是另一個單例，並且GUI將如何與整個遊戲進行交互。 GUI不會直接實例化任何其他對象。

因此，總結IBall和IBoard類只保存關於它們的數據，邏輯類處理所有功能。

我想知道的是：

1）這是一個明智的做法？

2）應該（通常）邏輯與對象/數據分開嗎？

3）我是否過分注意分離？

4）關於設計/結構的任何其他註釋

EDIT

我已經使用了幾個單身的原因部分是用於訪問在一個地方的數據的簡單不保持對象的保持所有的時間，也只是因爲它是一個單一的遊戲，不會擴展到高端或跨多臺機器。我明白，他們不是很好，也不是我經常使用的東西，但欣賞評論。

感謝您的意見和反饋。

Answer 1

如果沒有更好的想法，你很難評論你的設計。我知道它涉及球和板，但除此之外，我不知道。

儘量避免單身人士。是的，我知道GoF書中列出了它，我知道這是一種常見模式，但根據我的經驗，它最終成爲反模式。

您提到IBall和IBoard沒有關於它們如何交互的邏輯。這是否意味着他們沒有任何方法？他們的方法是否只是獲取私人數據的getter和setter？如果IBall和IBoard只是結構體（或其等價物），那麼它們不需要是接口。你可以充實你的描述，談談你可以發送給IBall和IBoard的消息種類嗎？

2）應該（一般情況下）邏輯與對象/數據分開嗎？

有時。如果你有普通的舊數據，那麼從普通數據中分離邏輯就沒問題。當然，那麼你不再做OOP了 - 你正在編寫程序代碼。我認爲你正在努力避免將任何行爲硬編碼到Ball中。也許其他實體應該負責決定球如何相互作用，但是你仍然有空間讓球參與決定。這是戰略模式（其他模式）將發揮作用的地方。想想現實世界中的事情是如何運作的 - 物理球和物理板如何協調它們的相互作用？如果他們互相交談，他們會說什麼？看看你是否可以在你的代碼中實現它。

最後，有關設計的一句話。我認爲想要「設計正確」是件好事。另一方面，這是朝向成爲architecture astronaut的道路。考慮你目前的代碼庫存在哪些問題。

• 難以重構嗎？
• 添加新類型的東西很難嗎？
• 太「硬連線」了嗎？

設計在真空中不存在 - 它是由世界的當前狀態。只要看看人們提出的一些瘋狂的手機概念藝術，就會看到壞設計的好例子。手機受當前技術的限制，而忽視現實世界限制的設計無非就是夢想。軟件也是如此。注意代碼告訴你它需要什麼，並且你會做得很好。

您編寫（完成）的軟件越多，您擁有的經驗就越多，美感也就越好。不要害怕「做錯了」會阻止你完成軟件。堅持下去，讓它工作，然後看看你從這個過程中學到了什麼。

Answer 2

您的細分看起來像是朝着正確的方向前進。不過，我不確定你是否試圖從邏輯中分離演示數據。看看MVC，觀察者和策略模式。

記住這一點：當您將應用程序設計爲鬆散耦合時，存在權衡。您可以使用更少的工作量來擴展應用程序，但是您的性能和內存使用量會很差。另外，我討厭這樣說，但不要創建不必要的界面。如果你知道你現在或將來在創建接口時要擴展對象的功能，那麼在實現它之前如果沒有考慮它的話。