從大學畢業後，我一直在爲大約3-4個月的時間進行程序設計（作爲一項工作）。走出程序心態
在大學時我被教過面向對象的編程，我覺得我對此有很好的把握，直到我開始研究真正的問題。
我只是不能做任何事情，但想出解決方案的程序代碼 - 雖然我使用類和基本的操作系統代碼基本上是程序內部，我知道有更好的解決方案，但我似乎不能匹配模式等等與我想要做的事情。
在使用oop技術真正開始編程之前，需要多長時間/多次練習 - 而不僅僅是使用充滿程序代碼的類。
此外，是否有任何建議，以便如何真正地設計解決方案正確的解決方案進展？
程序並不客觀上比面向對象的設計更差，但它是一個方便的工具。讓OOP很好地工作的核心方法是將你的程序視爲對真實世界對象的交互進行建模，每個真實世界對象都由程序對象建模，並且這些對象之間的每個交互都是一種方法。
但是，如果這不足以讓你滾動，也許你需要的是一些更多的工具在你的腰帶下工作。一個廣爲接受的來源是GOF book，它詳細地描述了構建程序的一些方法，重點是OOP。不過，謹慎的說法是，確保你應用的任何模式都非常適合這個問題，因爲如果你隨意應用它們，它會導致你和你的同事們頭痛不已。
+1，我希望我能給你+1這個答案中的每一個重點。 – 2010-09-20 15:55:02
除了@ TokenMacGuy的回覆，在設計課程時有一個有用的指導方針 - 他們應該知道怎麼不知道什麼。例如，在一個爲某些目的使用位置的系統中，應該知道如何找到他們的位置，而不是存儲它並記錄它。雖然不是靈丹妙藥，但要記住它是非常有用的，因爲它有助於使你的思維朝着適當的方向發展。
我認爲在你的情況下，你應該儘可能的開始編碼，甚至是程序。完成後，代碼運行，研究它，看看如何將它分解成模塊。找到應該放置在對象方法中的通用功能。同時，嘗試看看如何重構代碼以適應您閱讀的模式。及時，你會打開你在你的設計中做錯了什麼，並提高自己
看着Numerical Recipes in C你會體驗過程式編程。帶有無限參數列表的函數調用，程序流控制遍佈許多過程。採用一種簡單的算法，如「Runke-Kutta」，並將其移植到您選擇的OOP語言。封裝和消息傳遞是一種完全不同的思維模式。
OOP 是建模，正如TokenMacGuy已經說過的那樣，「真實世界對象的相互作用」。程序編程更多地關注「算法」。
學習OOP的一個步驟是將真實世界對象轉換/模型化爲類屬性和方法的能力。 Books Effective Java，Implementation Patterns，GoF幫助您在將真實世界對象放入代碼時選擇最佳實踐。
NR的第三個版本（你**必須**，前一個是15歲）使用C++和良好的OOP設計。 – 2010-09-19 21:47:54
@Alexandre C.我故意選擇了15年前的c版本。我認爲提問者學習了一種OOP語言，因爲他是第一種編程語言。因此，他可能沒有將經歷從程序轉移到面向對象。這並不是我的意圖，根本就不討論數字食譜的C版本。 – zellus 2010-09-19 22:02:07
我認爲這只是需要很多練習。
有人在這裏說： OOP是建模真實世界的對象。但這也是他們通常在學校告訴你的，正如我從OP那裏瞭解到的那樣，它確實沒有那麼有用。
當我看着我的代碼時，我發現它完全沒有任何真實世界表示的對象：數據庫映射器，對象工廠，表達式構建器等等。它們可能聽起來像真實世界的對象，但它們確實是真的什麼都不像。它們只是幫助我們管理程序的整個複雜性的抽象概念。
我認爲OOP的主要困難部分正是如此。你不能只看看你的問題領域，例如處理汽車，並說：我知道，我需要一個汽車類！即使您確實需要Car類，這些知識也無助於您決定真正放入其中的內容。顯然，你不能僅僅把那些在汽車內部處理過的數十萬個功能放在一個類中。那麼你如何管理它？如何切片？ Car類應該負責什麼？誰還應該瞭解汽車類？這些是難以解決的問題，除了程序的作者本人可以真正回答的問題外，沒有人會問。即使是最有經驗的人也很難在第一時間回答所有問題。
但我想有一些一般的良好的面向對象原則要遵循。保持儘可能低的物體之間的coupling。按照the law of demeter。請牢記SOLID原則。但最重要的是：一直保持DRY。
此外：不要侷限於面向對象的方法。學習函數式編程，正則表達式，編譯器構造，彙編語言以及您可以管理的許多不同的高級語言 - 僅僅瞭解OOP並不會讓您成爲一名優秀的程序員，但研究所有這些不同的方法和工具將允許你可以更加清晰地看待OOP，從而更深入地理解這個OOP事物的真正含義。
+1專門用於回答「但這正是他們通常在學校告訴你的，」我在閱讀現在最高票率問題的第一段時正在考慮wtf（http://stackoverflow.com/questions/3747352 /獲取-外的一個程序性，思維/ 3747393＃3747393）。真的，這是他們告訴你的第一件事。正如你從我的回答中可以看出的那樣，我會在你的最後一段中特別提到SOLID。 – eglasius 2010-09-20 05:31:16
裏用C實現COM對象，你就會明白
順便說OOP和程序之間的區別......，研究對象模型（COM例如，但這是1995年如此......）是掌握面向對象模塊化的優越性的好方法。帶上你最喜歡的大型圖書館（如果你使用C++或python，Qt是一個好的開始），並閱讀文檔，編寫小程序。
我只是不能似乎做什麼，但拿出解決辦法的程序代碼 - 雖然我使用類和基本的OOP技術的代碼基本上是程序裏面，我知道有更好的解決方案，但我不能似乎匹配模式等與我想要做的事情。
不要絕望，它在開始時是完全正常的。在處理它時要小心你的操作，確保你只應用模式來解決你在代碼中看到的實際問題。代碼應該很簡單，你可能有一個不需要任何高級技術的場景。不管你學什麼，都要記住你想要的是引入一些簡單的元素，這些元素會給你帶來好處而不會以一堆不必要的代碼/模式結束。
在使用oop技術真正開始編程之前，需要多長時間/多少時間才能開始編程 - 與使用充滿程序代碼的類相反。
取決於你的意思是否正確。你可能很早就學會了應用特定的方法，甚至可以實現一些非常酷的事情，但是要真正掌握它需要幾年的時間。我只是覺得有一些難題需要花費很長時間才能真正沉入其中。
另外，有沒有關於如何真正地設計解決方案以正確解決問題的建議？
我強烈建議您閱讀這兩本「電子書」S.O.L.I.D. principles and 31 Days of Refactoring。 SOLID上的代碼在代碼的設計方面非常出色，特別是在敏捷的環境中。重構之一可以幫助您識別現有代碼中的改進機會。
看看Effective Java by Joshua Bloch，第二版，Implementation Patterns byKent Beck。 – zellus 2010-09-19 20:40:28
@zellus：爲什麼不作爲回答發佈？ – SingleNegationElimination 2010-09-19 20:41:33
@TokenMacGuy：剛想過答案的信息太少。 – zellus 2010-09-19 20:53:45