軟體主廚的程式料理廚房

以往在 Json.NET 有 JToken、JObject、JArray、JValue 這些類別，可以讓我們在反序列化 JSON 的時候，不必一定要為其結構新增對應的型別，2021 年 11 月 .NET 6 釋出之後，內建的 System.Text.Json 也隨之升級，增加了 JsonNode、JsonObject、JsonArray、JsonValue，與 Json.NET 的那四個類別相對應，那我想要在 .NET Framework 使用 System.Text.Json 行不行？

小時候換新電腦都會感到興奮，覺得又有新玩具可以玩了，除了感受新硬體設備帶來的速度快感之外，還能體驗新作業系統帶來的新鮮感，有了一定的年紀之後，電腦變成工作用的工具，就只有希望它好好的不要出事，而且對於換新電腦也沒有什麼動力，因為習慣的軟體及配置，就要重新安裝跟設定，這幾天在替新電腦設定工作環境的時候，遇到了這個錯誤：

這個錯誤是在測試遠端桌面連線的時候跳出來的，在幾年前曾經遇過，當時解決之後想說應該不會再碰到了，沒想到又遇上了，寫一篇文章記錄一下。

多型在像是 C#、爪哇（用中文應該就不會被告了）這種強型別的物件導向程式語言，要將一個抽象類別的實例存到關聯式資料庫或是做序列化／反序列化，都需要另外處理，關於多型跟關聯式資料庫的對應方法我已經寫在這篇文章裡面，這篇要來寫寫多型如何做 JSON 的序列化／反序列化。

技術債是一種「任何有意或無意地做出可能不利於日後修改或擴展系統的錯誤或非最佳的設計決策所帶來了的設計導正工作」，我們說簡單一點，在軟體開發的過程當中，我們或許出於無奈、又或者始於無能，採用了會對將來修改或擴展系統造成麻煩的設計方式，而「改採用正確的設計方式的修改工作」就是等待償還的技術債。

軟體開發的過程當中，針對傳遞進方法中的參數避免不了一定要做一些像是邊界值、限定值、特殊值…等一堆你想得到的檢查，如果我們把條件檢查跟資料處理放在同一個程式碼區塊，同一區塊的程式碼長度就會增長，自然就會降低閱讀的順暢度。

我也想過用 AOP 的方式來解決，但是沒有想出來一個比較好的設計去處理不同的參數個數、不同的參數型態，以及要檢查的邏輯，想來想去 Decorator Pattern 雖然會多出一些類別，但能做好「關注點分離」，這一點點的 effort 是可以接受的。

前些陣子有人問我「Abstract 與 Interface 的區別？」，腦袋中閃過過去所有使用過 Abstract 及 Interface 的情境，整理之後給出我實務上設計的時候是怎麼操作 Abstract 與 Interface 的答案，回頭想想這樣有點文不對題，對方似乎也沒有得到答案，不過這樣的過程讓我有種見山不是山的感覺，促使我回頭想想在思考這個問題答案的過程當中不單純的點是什麼？以及為何我給出這樣的答案？

DES 加密演算法是一種對稱加密演算法，但是用來加解密的 Key 及 IV 需要固定長度，DES 的 Key 及 IV 長度大小都是固定 8 bytes，也就是說每次加解密的過程中都需要湊足 8 bytes 的 Key 及 IV，多了或少了都不行。

我參考余小章的文章 - [C#.NET] 字串及檔案 利用 DES / AES 演算法加解密，實作如何使用不固定長度的 Key 及 IV 進行 DES 加解密。

筆記一下有關於 OO 相關的守則，以便隨時能複習。

入手「設計模式的解析與活用」這本書，開啟我對 Design Pattern 的另一層想像。