紀錄一下寫程式過程發現的問題，感覺還可以再挖掘細究一下，先筆記下來。

事情是這樣子的

通常在設計 API 的時候會需要定義傳入的參數型別，以及回傳的 json 會長什麼樣子？為了定義 json 的結構，我們可能會使用 JSON Schema 之類的東西來撰寫 json 的規格，然後我們就可以根據這份規格來驗證彼此使用的 json 是不是正確的？確保資料沒有壞掉或是格式錯誤？然後發現這樣子的事情好像在以前學 type 的概念的時候也是類似這樣子的狀況。

什麼是 type ?

一開始我們在接觸到 type 概念的時候，大概會從 string, number, boolean, null 這些基礎型別開始，然後透過 object 和 array 這兩種容器類型把四種基礎型別合成你想要的資料結構。

程式語言通常會提供基礎型別常用的操作，如數字四則運算、邏輯運算、字串操作、陣列操作…等。

在 python 之中並沒有限制 x 從頭到尾都只能是一種 type，這種特性稱為「Dynamic type」
跟「Dynamic type」相對的就是「Static type」，以 C, C++ 為主要代表。

而 javascript 早期讓使用者覺得很貼心，但近期被人人喊打的自動轉型特性，被稱為「Weak type」
與之相對的是「Strong type」，以 python, java 為代表。

隨著對 type 的呼聲越來越高，從 javascript 催生了 typescript，算是替 javascript 提供了型別的保護

type 很好，但它能不能再做更多？

上面談的是關於基礎型別的部分，但通常人的需求不會遠遠只有這樣，於是後面出現了使用 struct, object, array 之類的容器組裝出更複雜的結構。這些結構更符合實際開發上的需要，再搭配操作結構的方法 (method) 之後，就逐漸演變成了 class，也就是物件導向、泛型、多型、繼承的開始。在這個脈絡下，class 和 type 其實是蠻接近的概念，就是「一組特定資料組合而成的結構」

如何定義一隻鴨子？ duck type

這是一個蠻常見的 type 判定準則，如果一個物件長得像鴨子，叫聲像鴨子，那麼我們就可以把牠當作鴨子。
也就是說，一個 type 所具有的 member 和 method 可以成為我們判斷 type 的準則。

回到一開始的資料格式 validation 問題

其實資料格式的 validation 是因為我們想要更進一步再限縮資料容許的範圍，避免錯誤的資料格式影響程式運作而誕生的。假如定義好驗證規則，那就可以讓程式按照規則去跑驗證，相對以前手工寫大量的驗證邏輯來說是輕鬆了不少。但就是要看實務上的資料彼此之間會不會有太多連動關係？如果有的話，那驗證邏輯寫起來就會變得相對複雜。

寫起來不亞於寫正規表達式，有可能現實世界的業務邏輯本身就是一堆 case by case 的規則組成的吧

以上，針對 type 和資料驗證所衍生出來的一點點小小思考過程