Simple Is Not Easy

if 條件式很常用, 但在有時因為使用不當造成閱讀或維護上的困難, 尤其是巢狀的 if-else 條件式對維護上造成很大的負擔, 這其實是有一些小技巧可以簡化 if 條件式的, 當然, 這些技巧不是萬靈丹, 使用上還是有些細節要注意的.

責任鏈模式在教科書上的典型範例是用在簽核流程上, 也就是一個任務/資料會依序流過各個處理節點, 每個節點會判斷任務/資料是不是在自己的權責範圍內, 決定要自己處理還是繼續往下拋.

前陣子公司專案剛好有一個類似情境, 但需求與教科書用法不同, 第一時間想到一個變形的作法, 而公司大神也提供了另一個更簡潔的做法, 趁還沒忘整理一下記下來.

完整的示範專案和文件

在網頁開發上, 處理 query stirng 是非常常見的情境, 要手動拆組 query string 也不難, 或是使用 .NET 本身就提供的相關功能讓這件事更輕鬆, 而兩種做法各有優缺點.

在C#中 const 和 readonly 都可以被當作常數來使用, 但兩者在特性上有許多的差異, 使用上也有一些需要注意的地方.

Switch-case 是一個經常被使用到的語句, 但當條件/情境過多的時候, 他會變得很肥大, 某種程度上造成維護上的困擾, 網路上也有不少人提出針對過大的 switch-case 語句的重構技巧, 例如: 策略模式.
但是策略模式會長出很多新的類別, 如果每個 case 的實作內容都很小, 這樣做似乎是有點複雜了, 所以這邊提供其他的替代方案(但會有一些限制).

C# 的 partial 修飾詞是相對少用的特性, 但在某些時候能起到很關鍵的作用, 所以還是知道一下比較好.
partial不是關鍵字但是他可以放在在class, struct, interface 以及 void method(…) 的前面作為修飾詞, 並將類型宣告或方法拆分成多個, 而編譯時會將所有區段結合起來, 所以對執行時期沒有影響.

前些日子, 收到一個小需求需要隨機產生一組帶大小寫字母和數字的亂數字串, 想說需求滿簡單的, 快速寫一下就寫完commit了, 然後過不久就爆掉了.
來看看究竟寫了些什麼鬼東西~

重拋例外有很多種方式, 包含 throw, throw ex, 使用 inner exception 以及 System.Runtime.ExceptionServices.ExceptionDispatchInfo, 或是不要重拋例外.

先總結選擇如下順序:

1. 最好不要重拋例外
2. 重拋優先選 System.Runtime.ExceptionServices.ExceptionDispatchInfo
3. 沒有框架支援則用 Inner Exception
4. throw 應該沒什麼情境需要用到了
5. throw ex 是具破壞性的作法, 除非是要刻意破壞堆疊追蹤

這篇會整理這幾種方法的使用與優缺, 並且另外提到 throw 和 throw ex 兩種方法對於堆疊追蹤的負面影響.

在設計 API 的時候, 常常會被參數過多所困擾著, 因為當方法有著過多參數時, 使用的時候容易眼花, 而需要增減參數時也很不方便, 這邊以常見的 HttpHelper 為例來說明。

情境是這樣的, 我在github上fork了一個專案過來, 並且做了一些修改, 後來發現我的上游專案有幾個pull request剛好解決的我一直解決不了的問題, 該怎麼把那些變更同步到我的fork呢?