Abstraction & De-duplication

在寫程式的過程中免不了遇到重複的部份，解決重複唯一的方法就是做抽象：

• 用變數/函數代替整個 expression,
• classical OOP 用 class 與 interface 來封裝資料與操作；
  FP 用 ADT 與 higher-order-functions 來抽象資料與操作 ⊕ Algebra Data Type
• design patterns 更進一步抽象出了用上述抽象的使用方式
• …

但是在做抽象的過程也會帶來一些問題：

• 這個抽象正確嗎？
• 建立抽象需要更多層次的理解，值得嗎？

Wrong abstraction

我覺得要在寫程式的當下意識到抽象是否正確是有點難度的，

• 將重複的片段改寫成函式時(Bottom-Up)，很容易不小心踏入 The Wrong Abstraction 中提到的 sunk cost fallacy 陷阱

If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is incorrect.

• 規劃一個新的程式架構時 (Top-Down) , 若是不夠了解需求，很容易寫出不敷使用的設計

錯誤的抽象也會讓人需要花更多力氣來理解、也需要費更多工來修正。

Everything is a Trade-Off

duplication is far cheaper than wrong abstraction⊕ The Wrong Abstraction

但是，如果不建立抽象，我們還是得付出代價：

• 需要更多的 mental stack 來認識到程式的重複
• 需要更多的心力來區分看似但不盡相同的程式片段
• 需要更多的力氣來維護重複片段的修改

不管怎麼選都要付出代價，我們也只能盡量選代價小的那一邊了。因此，更關鍵的問題可能是「該抽象到什麼程度」

Non-conclusion

沒有結論，我覺得替代方案是：