To-Do Calendar - Day17 改善參數傳遞
上一篇實作了為原子習慣追蹤查詢功能添加查詢條件，這篇要來改善查詢條件參數傳遞到 Dao 層的方式。
原本作法
- 直接將 habitId、year 這兩個參數，傳進去到 habitTrackerService 的 getHabitTracker 方法
- 因此 HabitTrackerService 的 getHabitTracker 方法定義，就必須要填上 habitId、year 這兩個參數
- 以此類推，HabitTrackerServiceImpl、HabitTrackerDao、HabitTrackerDaoImpl 的 getHabitTracker 方法也都要定義這兩個參數
HabitsController class HabitTrackerService interface HabitsServiceImpl class HabitTrackerDao class HabitTrackerDaoImpl class
雖然目前這樣的作法，也是可以實作出正確的結果，但這樣的作法，在程式的維護上，就會變得比較麻煩。
試想可能情境
- 假設查詢條件非常多（像是報表），有十幾個查詢條件的話，就要在每個 getHabitTracker 方法定義十幾個參數，而呼叫方法時填錯參數的機率就會增加 → 可讀性差 ∑(✘Д✘๑ )
- 假設今天客戶要求要再增加查詢條件，那我們的程式就必須大費周章地從 Controller 層一路修改到 Dao 層才能達成需求 → 可擴展性差 (ﾟдﾟ≡ﾟдﾟ)
Info
可擴展性是一種設計概念，代表了我們對未來的一種預想，我們希望在現有的架構或者設計基礎上，當未來某些方面發生改變的，我們能夠以最小的改動來適應這種變化。改動越小，並且對這種變化的適應性越好，我們就會說這個設計的可擴展性是非常好的。
改善方法
我們可以建立一個新的 class，在裡面去存放這些端傳遞過來的參數，最後再一口氣傳遞過去，去提升程式的可維護性。
- 先建一個 dto package
- 接著在 dto package 底下建立 HabitTrackerQueryParams class
- 在 HabitTrackerQueryParams 裡面添加在 getHabitTracker 方法中想要傳遞的參數
HabitTrackerQueryParams class
- 回到 HabitsController，在 getHabitTracker 方法裡面建立一個 ProductQueryParams 的物件
- 將前端傳過來的參數的值一一 set 到 productQueryParams 的屬性
- 最後將 habitTrackerService 的 getHabitTracker 方法裡的參數改為固定傳遞 productQueryParams
- 以此類推，HabitTrackerService、HabitTrackerServiceImpl、HabitTrackerDao、HabitTrackerDaoImpl 的 getHabitTracker 方法也都要改接 與傳 productQueryParams
HabitsController class
HabitTrackerService interface
HabitsServiceImpl class
HabitTrackerDao class
HabitTrackerDaoImpl class
當我們這樣改寫之後，以後不論在這個 productQueryParams 裡面去添加了多少新的變數，就不用再去修改 Service 層還有 Dao 層的 getHabitTracker 方法的定義了！所以說在開發時如果能適度地預留擴充的空間，就可以預防掉未來很多阿雜的問題囉～ ଘ(੭ˊᵕˋ)੭* ੈ✩‧₊˚