很多人會思考一個問題
我沒有對象 怎麼了解面向對象？？？
好吧 這個問題确實有點棘手
好了，言歸正傳。還記得高二的時候，我拿了一個星期的零花錢去淘寶上買了一本《java從入門到精通放棄 》，以為憑借自己的高中數學水準加之浸淫多年唐詩宋詞的文言文了解能力可以在成為程式員的電視劇裡多活兩集。
然而
其實買書前的一個星期，我剛給自己的索尼智能機刷成磚…買這本大厚書就是為了搞清楚，手機還有救沒，聽說安卓是用java寫的
果斷被對象勸退
這本書看了大概有一個多月，主要是利用暑假的時候零零散散的看，前面的資料結構都還好，就是到繼承，多态，接口這兒就不行了，很是費解。
再找對象
從頭想想這件事情，書上都有說到搞一個類出來是為了讓人更容易了解
？？？小朋友 你是否有許多問号
這應該叫更抽象了。本來好好的幾個資料類型和流程邏輯放在一起為啥就成了一個...對象。對不起，這跟我想象的對象不太一樣，我以為是這樣的
咳咳…都水的快忘了這是一篇技術部落格了
其實，我這菜雞水準就不從技術層面上分析了。這次就想就我而言，為什麼難以了解面向對象開發。想到哪說到哪，也沒打草稿
1. 程式員很懶，他們不想重複造輪子
可以明白整個面向對象開發過程都是在省事兒，比如搞一個類，類下面有類屬性，類方法。就是為了以後隻要用到這個功能，我就打這個類名調用，省事兒。
2. 雖然省事兒了，但是我還要足夠靈活
事兒是省了，但是需求多種多樣，一個固定的類實作不了千奇百怪的需求，這時候就需要，讓這個類靈活起來，繼承，接口都是為了這個目的。
3. 子產品化的思想
為了達到一個又靈活又省事兒的目的，最終不得不走向子產品化之路。在開發功能之初，就把未來可能出現的新功能添加的位置預留出來，這就誕生了抽象類。但是又由于開發功能的人可能有很多，為了規範大家做出來的功能可以互相相容，這時候接口出現了，功能的輸入和輸出就被規範化了，避免了資料在不同功能子產品間傳遞的時候出現類型不比對的問題。
總結
說到底還是用得少，邏輯的執行出來才容易了解，還是多敲代碼，多實踐才能把書本上學到的東西融會貫通。