心得之——程式的修改和拓展
作為一名程式設計師或者說了解過程式的人來說，我相信常常都會聽到別人說乙個好的程式最基本的就是良好的可拓展性和易修改性（大概是這個意思，原我給忘了），那麼到底什麼是良好的拓展和已修改性呢，我們又為什麼要保證程式的修改和拓展呢？這是我從大學時期就一直在想的問題。
我記得當時我們老師的回答是：假如你現在要去賣水果：蘋果和香蕉，那麼你定乙個方法 public void sellfruit(蘋果物件，香蕉物件)，好了現在你直接用這個方法你可以去賣水果了，但是問題來了，如果某一天你發財了，你可以賣5中水果：水蜜桃、蘋果、香蕉、葡萄和柚子，那麼你是寧外寫乙個方法 public void sellfruit2(蘋果物件，香蕉物件，水蜜桃，葡萄，柚子)，還是說還是在原方法上呢？當時我想了半天，直接就暈了，然後老師就說，不管是水蜜桃、蘋果還是香蕉不都是水果嗎？我一聽，對啊，當即就把方法改了public void sellfruit(水果物件），其他所有水果的物件繼承水果物件，老師笑了笑，直說你的物件導向還挺喜歡用.....請問一下各位，你能看懂老師到底是在說什麼嗎？
其實後來自己接觸的程式多了，也就慢慢的有了乙個大概的了解，其實換乙個例子來說：你要讓某個服裝廠改服裝：test(顏色，型號);結果你把衣服拿回來客戶還不滿意說還要加特點，行這個時候你就重寫test(加特點);那麼試想一下如果這回客戶說我想衣服的袖子一邊長一邊短，你是否又要重寫方法呢？其實不用，首先他要改的是衣服這個物件，那麼假如衣服這個物件目前一共的特點包括：顏色、大小、款式、袖長、腰圍、胸圍，test（衣服物件）那麼在這個方位內的屬性就算客戶改需求是否我們也就不用再改方法呢，哈有一種情況，這個時候客戶說衣服是有領的，我要換成無領，那麼我們也只要在衣服物件中新增衣領屬性就行，這是大大的減少了我們的修改量。可能這個說的也還是很抽象，特別是對於沒有更改過需求，或者業務層次區分不夠明顯的，可能理解起來就感覺沒什麼區別，或者還會覺得更麻煩。
其實在真正的乙個專案中，前期需求不代表永遠，就算專案上線了，也有可能加功能，對專案進行拓展，一般來說修改是每個程式設計師常經歷之事，改自己的**還好，但是要是你要改的是別人的**，而他的**裡邊所有方法全是用的屬性，引數值在傳遞，那麼我想需求稍微一變那你就要瘋了吧，就比如說:dao、servces、實現類、介面，物件，如果你使用的是引數值傳遞，那麼需求一變不好意思，dao、servces、實現類、介面就都得更改，但是如果您使用的是物件傳遞，那麼你只需要更改物件和實現類就好，這是大大的減少了我們的工作量，提高了工作效率，最關鍵的是心情還好了。以上呢就是簡單的說了一下程式的修改
對於程式的拓展性可能更多的就涉及到泛型和反射，當然也有通過物件屬性實現拓展，那麼我們還是先舉個列子，簡單的說一下為什麼要提供拓展性。
還是以服裝廠修改衣服舉例，我相信乙個再窮的服裝廠肯定都不是只賣衣服，可能還有褲子，或者其他的，或者說衣服都不止一種品種，那麼對於不同的物品是佛偶我們還要去建立不同的方法呢，那麼當我們想修改乙個新的物種的時候，恭喜你，:dao、servces、實現類、介面，物件，你都需要修改，但是反之假如你用的是泛型和反射，那麼你只需要提供乙個方法test(?),然後再在實現類中利用反射獲取物件。class，獲取物件屬性，那麼你的所有問題的解決了，當然前提是你的所有物品的大概屬性還是應該一樣。
總而言之，言而總之：物件導向、泛型、反射、繼承就是你要攻克的堡壘，加油吧！
修改blog背景和顏色的心得
根據我的小小經驗，使用css來進行定義比較方便 準確，而且在多個 內使用時，效果更顯著。什麼是css？在blog的 上，一般可以見到形如以下的 以下內容為程式 注意是這些定義要插在之間 最簡單，如果要設定整個頁面的背景。你可以在css中新增一項 body 那麼整個頁面的背景就是 了 或者自定義blo...
程式猿的能力拓展模型
聽人說了乙個詞兒，叫作 comfortable zone 中文是 舒適區 這個詞兒讓我瞬間聯絡到程式猿的能力邊界問題，我畫了能力拓展模型圖。例如以下 我認為這個能力拓展模型，適用於乙個人的方方面面。但這次我打算僅僅拿程式猿來扯一下。圖中左側是我們的現狀，最內層的原型是我們感到舒適的區域。我稱之為 舒...
陣列的理解和拓展
1 什麼是陣列 陣列就是一組資料的集合 其表現形式就是記憶體中的一段連續的記憶體位址 陣列名稱其實就是連續記憶體位址的首位址 2 關於js中的陣列特點 陣列定義時無需指定資料型別 陣列定義時可以無需指定陣列長度 陣列可以儲存任何資料型別的資料 比如說乙個元素儲存整型，乙個元素儲存字串型，這個在js中...