又往前推進了一個版本,這次來到 C# 7.3 ,而這小改版有一個地方讓我非常有感,
那就是「泛型的條件約束」,所以來特別來介紹,以前在設計泛型的時候,很常使用到「列舉」
,但就是無法直接使用關鍵字 Enum,需要轉念一下,原來是要使用 struct 關鍵字...
又往前推進了一個版本,這次來到 C# 7.3 ,而這小改版有一個地方讓我非常有感,
那就是「泛型的條件約束」,所以來特別來介紹,以前在設計泛型的時候,很常使用到「列舉」
,但就是無法直接使用關鍵字 Enum,需要轉念一下,原來是要使用 struct 關鍵字...
這篇名字有點長,這是無意間發現的狀況,好奇心作祟筆記一下;實務上不可能將既有運作中的資料
表隨意的轉換型別,更不用說兩者類型所儲存的內容天差地遠,轉換也沒意義;
踩到這系列的雷,以往都是看別人解決,終於發生在自己身上,順手紀錄一下;
情境是抓了某個版控的專案,一抓下來,執行build就炸掉...
我認為單元測試主要用來驗證程式設計邏輯與系統功能正常運作的技法,期望哪些情境下,確保我們的設計都有考量到,
並且滿足需求,另外再未來擴充與修改系統功能下,依然能 維持既有的測試案例(不會改東壞西),
增加對軟體的信心度。但,再開始之前,
這個語法之前一直沒有相對必要的實際應用,若真需要列表分群,覺得使用表格呈現較好閱讀,但若僅是單純的文字
表達作為備註欄位,覺得是個不錯的解法...
Reflection 很常使用,雖不是專案標配,但一年之內總會有使用它的地方,實務上往往與多型搭配起來完成動態實例化物件的技法;
但現實中既有程式難以捉摸,不一致的撰寫風格,或意指相同事務,但文字與設計方式卻充滿弔詭。這次遇上了,
還好C# 內建函式可以幫忙解決。