引言：
列舉型別給我們的開發帶來了很多的好處，它是個非常典型的乙個單例模式，但這樣做優越的功能，給我們帶來的不全是好處。
當我們開發的介面給別人呼叫時，往往因為業務需要，新增乙個字段型別等等，就也就需要呼叫端一起更新api包，這裡想方設法的去解決這個問題，但這裡深深自問題，這是否算是在破壞著這個列舉型別 了呢？
問題：
為了不去經常性的去增加列舉型別的字段，我選擇了加方法給出設定值的介面來做個測試，但這樣的
測試出現了乙個問題。
示例：
列舉類如下：
/**
* @desc 配送物品型別列舉類
*/public enum goodstype
goodstype(string value)
private string value;
public string getvalue()
}
！！！ 發現問題：
在這裡面出現了乙個問題，當這個列舉類在序列化和反序列化之後，對應的值全為預設的引數值了。不管你怎麼改變它的值。
以下就做個實驗：
服務端：
public class server
}
public class client
}
埠已啟動...
1服務端測試完成
客戶端控制台顯示：
before write : goodstype = 22
after write : goodstype = 22
客戶端測試完成
問題原因：
在傳遞列舉型別時，其實io中，有專門對它的傳輸方式，原始碼如下：
private void writeenum(enum en,
objectstreamclass desc,
boolean unshared)
throws ioexception
而不會把gift這個值給傳遞過去，當到傳伺服器端的時候，伺服器端轉換過來的也是該列舉類，對應的伺服器端gift類的值而已。
結論：
其實這樣的變動想法是在場景應用上而引發了一次思考，這樣的做法，其實已經在破壞了列舉類的初衷了。罪魁禍首的人是我，但經歷這一次的風暴，讓我從中對列舉類了解更深刻了。呵呵。
小菜破壞了小海藻
話說時下電視劇集 x居 正在熱播中。一貫兩耳不聞窗外事，一心一意為人民服務，廢寢忘食寫 的小菜也被這一夜之間傳遍神州大地的 x居 感染了，寫了一半就跑去看了 電視劇集看完了，小菜繼續寫 了 我靠，看來 x居 的影響真不小啊，連小菜也被影響了，堆疊被破壞了，如果你運氣好，就能看到列印出兩個 俺們是80...
讓你覺得破壞了封裝性的擴充套件方法
擴充套件方法 源於對擴充套件方法的了解是來自list的where order groupby等方法的使用，智慧型感知提示這些方法都是擴充套件方法，於是msdn上查閱後總結如下自定義擴充套件方法 將字串轉換為int，拷貝 namespace mycommon 微軟規定，擴充套件方法 1 必須是靜態類和...
到底是誰害了誰？
到底是誰害了誰？和乙個獵頭朋友聊天，他說最近在找乙個軟體架構師的職務，年薪30萬。不知道朋友們對30w的年薪是什麼概念，但看了要求你就會更驚訝。如果真象jd裡面要求的那樣年薪30w實在是有點低了。他說乙個公司的做hr做的好的也不只這些，何況還有年終獎，績效什麼的。在中國做技術的其實是很慘的。從以前拼...