程序猿應該瞭解的內容以及程序猿如何強迫本身學習（思考篇）

            上一篇文章LZ給出了做爲一個程序猿必須掌握的知識之一，也就是咱們常說的算法，後面還給出了有關算法學習的建議，但願這些內容能給猿友們一些幫助，同時也但願這一系列文章可以解答一部分猿友常常問LZ的問題。

            此次LZ思來想去，決定給文章起一個思考篇的名字，其實按照這個思路起名字的話，上一章應該叫作邏輯思惟篇，而不該該叫算法篇。不過因爲本次的重點在於思考，所以起這個題目也無可厚非了。

 

引言

 

            前面LZ說過，程序猿必須掌握的知識，其中之一就是算法，這裏面很重要的一個緣由，不只僅是爲了應付一些公司的面試，更重要的意義在於，能夠鍛鍊各位的邏輯思惟能力。做爲一個程序猿，或者說做爲一個優秀的程序猿，邏輯思惟能力是程序猿能力當中很重要的一項。

            那麼本次LZ就來和各位猿友探討一下第二個必須掌握的知識，而這部分知識則重點是爲了鍛鍊各位的思考能力，由於善於思考也是程序猿或者說一個優秀的程序猿必備的品質。

 

面向對象

 

            看到這個小標題，估計大部分猿友都猜到了，LZ所說的鍛鍊善於思考的能力的方式，就是經過掌握面向對象的知識，從而激活咱們的大腦裏的腦細胞進行高速的運轉。

            面向對象，是一我的盡皆知的名詞，它是如今幾乎全部的高級程序設計語言的設計思想，主流的語言包括Java、C#、C++、Objective-C、PHP等等。隨着計算機軟件的快速發展，軟件的規模與複雜性在穩步上升，所以傳統的面向過程的程序設計方式，會致使程序的維護性降到一個可怕的地步。

            這是因爲在面向過程的程序設計當中，全部的流控制都是由語言的流程控制來完成的，更通俗的講，也就是由if/else等一些條件判斷來完成的。所以不難想象，若是一個大型的軟件當中，沒有對象，沒有多態，沒有繼承，沒有封裝，而是充斥着一大堆的if/else之類的條件判斷，那估計不久之後會出現大批量這樣的新聞，「某某系統維護人員，不堪重負，跳樓自殺！」

            

對象範圍

 

            根據語言的特性來講，假若一個編程語言不支持面向對象的設計，那麼就已經註定，幾乎不會有人使用它來開發大型的應用軟件或者系統，就算是勉強開發出來了，估計也不會有人願意再去維護這個系統。在當今程序規模劇增的時代，做爲一個程序猿，若是不懂面向對象的設計思想，這幾乎已經註定，你真的也就是一個碼農了。

            可是凡事都有例外，並非全部的人都必須掌握面向對象的思想，所以爲了不沒必要要的爭議以及誤導某些猿友，這裏LZ仍是要先說一下咱們討論的對象範圍。

            簡單的來講，本文適合的人羣爲，如今以及未來或未來的很長一段時間內，都將以某種支持面向對象特性的編程語言爲飯碗的猿友們。除了這一部分人以外，其他的猿友LZ建議能夠點擊瀏覽器右上方的「小叉叉」，以避免接受誤導。如下所提到的程序猿，所有基於上面提到的人羣。

 

面向對象與工做

 

            面向對象與算法不一樣，它充斥在程序猿的工做當中，與工做是息息相關的。

            好比某個方法應該放在哪一個類當中（要符合單一職責原則）？某個屬性的訪問權限應該是私有的仍是受保護的（封裝）？某兩個類的關係應該使用繼承仍是組合（類之間的耦合關係）？

            上面這類問題還會有不少不少，這些通通都是面向對象相關的問題。若是有的猿友看到這些問題，發現本身彷佛從未思考過相似上面提到的一些問題，那麼LZ可能要告訴你一個不幸的消息，你目前極可能仍是一個真正的碼農。

            與算法不一樣的是，是否掌握了面向對象的設計思想，會直接影響你的代碼質量。換句話說，面向對象與平日裏的工做是息息相關的。這也使得咱們更加確信，掌握面向對象的設計思想，是一個程序猿必須作的事情。

 

小談LZ的面向對象之旅

 

            提及來，LZ第一次接觸面向對象的相關內容，應該是在某培訓機構裏，當時是負責面授課的一位老師提到的。從LZ的瞭解來看，這位老師也屬於偏心技術而且喜歡分享的一類人。

            依稀記得那應該是一節有關spring框架的課，這位老師當時在課上簡單的提了一下設計模式當中的策略模式，引發了LZ的嚴重好奇心，也是從那個時候開始LZ才知道，接口原來還能夠這麼用的，當時LZ和個人小同窗們都驚呆了。

            自那次之後，LZ看代碼和寫代碼的時候就不知不覺的養成了一種習慣，就是總會不天然的去思考所寫或者所看的代碼當中，各個類之間的關係，以後在培訓機構最後的分組小項目當中，LZ擔任組長一職，在編寫核心代碼的時候第一次使用了策略模式。

            以後LZ便進入了一家小型的互聯網公司，當時公司的框架使用的是一個開源的基於SSH框架的電子商務架構，LZ看到後瞬間就被SSH代碼的優雅給折服了。不過這個時候，因爲LZ的面向對象思惟尚且比較初級，因此不太能體會到框架中類的精妙設計。不過因爲此時LZ已經有了面向對象的思惟，也開始涉獵一些面向對象相關的書籍，所以在不斷的學習和思考之餘，仍是在逐漸加深着對面向對象的理解。

            後來LZ陸陸續續的看了一些與設計模式、重構等相關的書籍，再一次鞏固了面向對象的設計思想，並試圖將其應用於LZ如今所維護的項目當中，在這個過程中，LZ對於面向對象的理解依舊在不斷的加深。以後LZ便乾脆寫了一個設計模式系列的博文，並因文章風格迥異有幸被邀執筆，至今此書還在LZ的構思當中，但願不遠的未來它能夠出如今你們的面前。

 

LZ的小建議

 

            LZ之因此將本身學習面向對象的過程簡單的描述了一下，是想讓各位猿友意識到，在這個過程中，LZ其實一直在思考，並且能夠說是從頭到尾。從LZ的經歷也能夠看出，面向對象不只僅是程序猿必備的知識，更是牽動你思考的琴絃，只要你瞭解了面向對象的知識，不少時候會不知不覺的思考一些設計方面的問題，這也是思考與總結能力的一種鍛鍊。

            就LZ我的的經驗來說，LZ以爲面向對象的設計思想是一個長期培養的過程，而非一朝一夕的努力而至，它是一種思惟模式，是一種編碼習慣，學習面向對象的過程其實就是一個不斷思考的過程。

            面向對象通常都會與你的整個編程生涯相關，所以咱們應當儘早的接觸它，但不須要着急的掌握它，應當按部就班。

            根據LZ我的的學習經歷，LZ建議學習面向對象的過程，能夠分爲如下幾個階段，各位猿友也可根據自身適當調整。另外，因爲LZ是非計算機專業的半路出家之人，因此如下方法可能更適合非計算機專業的猿友們，不過對因而計算機專業的猿友們，應該也有必定的參考意義。

            一、初識階段：這一階段應該發生在你剛進入工做崗位的時候或者以前，或者更確切的說，應該在你能夠動手寫應用程序的時候就開始，不管是Web仍是App。這個階段能夠看下網絡上的文章，初步瞭解一些面向對象設計的基本內容，好比類之間的耦合關係（依賴，關聯、聚合、組合等）以及一些簡單的設計模式，例如簡單工廠、工廠方法、策略模式等。

            二、瞭解階段：這一階段應該發生在你工做一段時間以後，此時你對你開始瞭解的面向對象的簡單內容已經思考的差很少了。此時應該選取一本入門級的面向對象的書籍，較爲系統的瞭解一下整個面向對象設計思想的內容，而不該該依舊只是在網絡上獵取一些零碎的知識。

            三、實踐階段：這一階段發生在你讀完入門書籍以後，此時便應該開始實踐階段了。不過實踐的時候不要輕易拿工做中的項目開刀，能夠嘗試寫一些本身的小工具，而後將面向對象的設計思想應用進去，深刻的體會它給你的小工具帶來的好處。

            四、提升階段：在通過實踐階段之後，便應該嘗試提升本身的理解，以便在真正的工做當中能夠正確的應用。此時能夠選取一些較爲深奧的面向對象書籍進行研讀，加深本身的理解。

            五、取經階段：此時你應該已經研讀完了一些較爲高深的面向對象設計書籍，如今能夠進行下一個階段了。找一個優秀的開源框架，完全搞清楚它的設計，深刻體會其中的奧妙，向那些優秀的開源框架設計者們取取經。

            六、大成階段：假若你已經成功的研讀完一個優秀的開源框架，並深刻的理解了其中的面向對象的設計思想。那麼恭喜你，你的面向對象的設計思想已基本大成。此時你已經徹底能夠嘗試寫出一個優秀的開源框架，供世人們膜拜。

            總結：以上6個階段的主線，主要就是思考。大體總結起來就是，先經過網絡或者書籍等渠道，學習一些面向對象的知識，而後不斷的思考、實踐與總結，等現有的知識理解的很透徹了，再獵取一些相對更加高深的知識，再思考、實踐以及總結，以此類推。

            面向對象的設計思想沒法一朝而就，只能隨着經驗的增長，逐漸的加深理解。假若在你未參與過任何的實際項目以前，哪怕你將書籍讀爛了，也幾乎不可能真正的理解面向對象這四個字。又或者你確實是理解了，可是真正用起來，仍是會顯得十分生澀。

            面向對象是人生的一次長征，咱們應當儘早上路，並加快咱們的腳步。但不要將本身想象成孫猴子，翻個跟頭就想到達終點，好好的作個唐僧，徒步取經纔是正道。