理想化編程測例子還很多，我就拿做接口這個例子說事吧！

      現在一般的接口都是給的json格式，Json是一種特殊的字符串（就像string是特殊的引用類型，至于怎樣特殊問題留給你了）！XX提供一個接口是一個字符串，然后我問是怎么搞得，他說拼接，此時此刻，大家覺得有問題嘛？

      你拼接Json串，總有一天你會感覺到日了狗。。。。（包括在js拼接json串也是一樣，一定要拼json對象！一定要拼json對象！一定要拼json對象！重要的事情說三遍！然后再用JSON.parse()和JSON.stringfy()去操作。

      XX提供的結構就是一串字符串，為什么不序列化?。。。〕霈F占位符怎么樣？XX曰：我們數據不會出現！這么肯定？這就是理想化編程的可怕！

      我跟到底層原來寫的這么鬼：

     public string ToJson()        {            return string.Format("{{/"para1/":{0},/"para2/":{1},/"para3/":{2}}}", para1, para2, para3);        }

      此時我已無力吐槽。。。。為什么不序列化(Serialization)成json?

      下面還有關于反序列化成model。為什么用強轉？強轉為什么不加Try catch？

       LModel codelist = (Model)JsonConvert.DeserializeObject(strJson, typeof(Model));

      其實也沒必要用Try catch，用as就行

      關于強轉和as的區別：強制類型轉換：轉換不成功會拋出異常，對引用類型和值類型都適用。as運算符：轉換不成功得到一個null值，不會拋出異常；僅適用于引用類型，不能用于值類型。

      LModel codelist = JsonConvert.DeserializeObject(strJson, typeof(Model)) as model;

     這不就OK了。。。。

     做接口要注意的地方（一家之言，歡迎拍磚）：

     1，標準的接口文檔和標準的接口數據；

     2，性能；

     a、SQL語句性能，查詢更快

     b、緩存，減少數據庫壓力

     c、數據量，能不能一次把數據拿出來

     d、生成壓縮gz文件，減少網絡傳輸

     先以json為例吧，像編程理想化的例子還很多，比如不寫后端驗證，我們改怎么防御攻擊。此恨綿綿無絕期，吾將上下而求索！我是不是有點較真了？？？？