解耦介面呼叫者與介面實現者

• 在介面設計當中，如果涉及到同時返回多個關聯物件，如問題Question，又包括問題選項QuestionOptions，此時一般想到的做法是使用一個Map，然後將qustion和questionOption分別作為key，然後返回，這種做法使得呼叫者需要檢視介面實現程式碼，才能明確知道這個map裡面放了什麼東西，造成介面呼叫者與介面實現者緊密耦合，故可以設計一個新的DTO物件，封裝這兩個資料，這樣的好處：
  • 既可以增加介面可讀性，同時也能提高拓展性，之後又新資料，則可以直接增加一個欄位。同時在介面傳參方面也可以採用類似的做法。從而達到開閉原則和最小知識原則；
  • 對Java程式碼而言，可以以型別安全的方式去獲取資料，而不需要像Map一樣，需要使用一堆的強制型別轉換，如：Question question = (Question)map.get(“question”);

作為介面卡或者代理，用於轉換或拓展已有model

• 如TaskProductFilter是過濾器實體類，裡面包括gameType1，gameType2兩個欄位，而所需查詢的資料欄位game_type則是以“gameType1 > gameType2”的字串方式儲存，所以在查詢中不能直接取gameType1和gameType2，為了減少在業務邏輯程式碼中增加一堆處理和判斷，則可以抽象出一個DTO物件TaskProductFilterDTO，並且繼承TaskProductFilter，在TaskProductFilterDTO中增加gameType欄位，並進行處理。同時若查詢中又要增加其他實體TaskProductFilter沒有的欄位輔助查詢，則可以在TaskProductFilterDTO中增加，而不需要對資料庫實體TaskProductFilter進行任何修改，從而達到對拓展開放，對修改關閉。