最近想寫一個 email domain 的檢查器，想要提供 wrapper ，讓使用者能包一層 cache 或是給 testing 用的 dummy 。這個時候我就想到了 Rack middleware 的那種模式。

只不過我想說這麼簡單的程式庫，做出 middleware DSL 來是否太過浪費，所以就想說不要做成 middleware 模式那樣剝洋蔥的感覺。所以就打算平面化，用 array 把 wrapper 存起來，每個 wrapper 都有一個 valid? ，依序呼叫後有 true 就提前 return ，false就呼叫下一個。

實做後，發現我忘了應該要 cache miss 跟真正的檢查後，再把東西存起來。要這麼作就只能真正執行檢查後，再迴圈跑每個 wrapper 的另一個方法去存起來。這個時候才發現 middleware 的精妙之處。首先同一個方法就會同時負責 input 跟 output 。然後測試也比較簡單，各個 wrapper 可以獨立寫測試。用我的土炮方法，就得把 wrapper 套在 core class 上進行 integration test，並且確認裡層的東西在 cache hit 時就不會呼叫。

感覺自己因為想減少 method 呼叫層次，似乎只是一種 premature optimization 囧。