如何從面向對象的編程思考？

Question

我一直對遊戲編程感興趣，並嘗試閱讀很多關於面向對象的書籍。問題大部分是書籍向你展示了代碼，並說「在此添加」，「在此添加」，但它們未能解釋OOP的「大局」而不是跳轉。我想知道我如何從面向對象的角度來思考。例如，我讀過這個線程Object Oriented application problems in game development，它給了你關於如何認識你的課程的一些很好的見解（例如，玩家「有」，「可以」......世界「聽」）。我希望得到一些幫助，這是一種思考的方式，以便爲正確的問題制定正確的問題，以便計劃好哪些事情應該留給「玩家階級」去做，哪些事情要離開「世界級」去做，哪些我想要回答「爲什麼」而不是「希望」，我不想要代碼，我希望OOP的問題或思維集成爲一種自然的方式組織代碼的方式。

例如，如果我正在處理碰撞檢測。我是否應該讓這個「世界」來檢查？，我應該讓它給球員檢查嗎？我應該問自己哪個問題？

對不起「廣泛」的問題，但任何事情都會有所幫助。從好的「書」到一些提示。

PD：我沒有MUCHO編程經驗

最好的問候，

Answer 1

我讀的「面向對象的思想過程」早期版本，發現這本書在理解整個OOP模式有極大的幫助。

http://www.amazon.com/Object-Oriented-Thought-Process-3rd/dp/0672330164/

Answer 2

我猜「格羅克」面向對象編程的概念，最好的辦法就是去思考的代碼模塊或積木 - 寫代碼，以便它可以以這種方式模塊化，然後就可以通過簡單地根據需要調用它們而不是一遍又一遍地寫入相同的代碼，隨時重用它們。它既是一門學科，也是一門教學科目。記錄代碼也很有幫助，因此當您稍後再回來重用它時 - 您知道需要什麼類型的參數，它生成的輸出是什麼類型，以及它如何執行您編寫的內容。

Answer 3

停止閱讀書籍，並在那裏和程序。學習Java。使用一本書來做，但不要只是通過動作，不要下載代碼自己寫。一開始你會想知道OOP有什麼意義，但是你會遇到更復雜的問題，你會開始欣賞OOP給你的自由。諸如繼承，封裝和多態等事情現在只是你的條件。你知道他們的意思，但你沒有編程到足以使用這些概念。一旦你使用它們並且創建了可以體現這些概念的類，那麼你就開始學習真正的面向對象編程。你不應該專注於製作遊戲OOP，你應該專注於使OOP適合你的遊戲。

故事的寓意是去程序。

Answer 4

正如你所說，這是一個非常廣泛的問題。憑藉經驗，您將更清楚何時使用什麼。

雖然很高興知道「原因」，但請記住，瞭解「原因」爲您瞭解「原因」奠定了良好的基礎。

現在，回答你提出的具體問題。把公衆想象成你會在API中放置的東西。如果你有一個「玩家班」，你想讓你的其他代碼處理它嗎？你想在某種意義上與它交互。什麼是與「玩家類」互動的界面？那些你的界面應該是「公共」的。

那麼，什麼是私密的東西呢？例如，如果玩家類的屬性必須在有效範圍內（比如說在1到100之間）。你如何防止人們（代碼的其他部分）腐敗？你使用私人的。這樣可以防止其他人將值設置爲1001.這樣，如果它進入了不良狀態，就會知道這是該類的錯誤，而不是代碼的其餘部分。

至於設計，請記住設計更改。當你第一次開始使用你的程序時，你可能會決定一個班級應該進行碰撞檢測。 （也就是說，你的「世界」有一個碰撞檢測器）也許起初你只是用碰撞檢測器寫下你的「世界」。之後你將代碼重構出來，並有一個名爲「碰撞檢測器」的類。之後，您可能會決定將它放在其他地方，但這很容易，因爲您可以讓另一個對象「擁有」碰撞檢測器。

要點是，如果你讓你的代碼足夠模塊化，這將很容易。沒有硬性規定。你首先用你想到的設計寫你的代碼。一路走來，你會找到更好的方式做事。

Answer 5

寫入，寫入軟件。人們對OOP產生了太大的影響。這只是一種實現某些設計原則的方法，如模塊化和低耦合。您可以嘗試一下，看看代碼是什麼 - 良好的代碼，如何使代碼更加靈活和可維護。那麼你就會理解導致一個好設計的原則，無論是純粹的功能性，程序性的，面向對象的，還是其他任何範式。

Answer 6

我認爲學習面向對象的關鍵在於編寫代碼，但是開始考慮如何對現實世界進行建模 - 即汽車對象具有門，輪胎，引擎等屬性，而這些行爲可能是啓動引擎，換油等......釋放你的思想，並用一種​​方法來思考問題，這將涉及到如何使編寫代碼更簡單和更復雜。有些問題是非常複雜的，但是面向對象可以幫助你分類並以真實世界的方式來思考問題。你可以做到這一點......只是開始嘗試....