01
基礎題
辨識淺層包裝模組
測試問題
審查以下 TypeScript 結構：OrderLookup 只有 getById(id, includeItems, includePayments, includeCustomer) 與 getMany(ids, includeItems, includePayments, includeCustomer)，兩個方法都只是把四個旗標原樣轉傳給 Repository；六個呼叫者各自重複『訂單詳情需要 items+payments+customer』的組合。請用 module、interface、depth、leverage、locality 與 deletion test 分析，並提出一個更深的介面草案。不要新增目前沒有第二種實作的 adapter seam。
載入前 · 0 個 Skill載入後 · 版本已核對再次確認 · 0 個 Skill已確認模型套用 Skill三個環境皆已清理
未載入 Skill844 tokens · 36908 ms
目前的 `OrderLookup` 是淺模組：它雖然增加了一層名稱，卻沒有吸收任何複雜度。
| 面向 | 審查 |
|---|---|
| module | `OrderLookup` 沒有封裝查詢意圖或載入策略，只是 Repository 的轉接層。 |
| interface | 四個位置參數讓呼叫者必須理解 items、payments、customer 的載入細節；`getById` 與 `getMany` 還重複相同旗標介面。布林參數也容易因順序錯置而出錯。 |
| depth | 介面複雜度接近實作複雜度：呼叫者傳四項，實作再原樣傳四項，深度很低。 |
| leverage | 六個呼叫者都要重建「訂單詳情」規則。修改詳情內容時必須修改多處，這一層幾乎沒有提供槓桿。 |
| locality | 「訂單詳情包含 items、payments、customer」這項領域決策散落在六個呼叫者，而不是集中在最了解訂單讀取方式的模組中。 |
| deletion test | 如果刪除 `OrderLookup`，讓呼叫者直接呼叫 Repository，系統中的概念與重複幾乎不會增加；主要只是少一層轉傳。這表示目前抽象沒有承擔足夠責任。 |
更深的介面應表達呼叫者的意圖，並把關聯載入組合藏在模組內：
```ts
export interface OrderLookup {
getDetails(id: OrderId): Promise<OrderDetails | null>;
getManyDetails(ids: readonly OrderId[]): Promise<readonly OrderDetails[]>;
}
export class OrderLookupService implements OrderLookup {
constructor(private readonly repository: OrderRepository) {}
getDetails(id: OrderId): Promise<OrderDetails | null> {
return this.repository.getById(
id,
true, // items
true, // payments
true, // customer
);
}
getManyDetails(
ids: readonly OrderId[],
): Promise<readonly OrderDetails[]> {
return this.repository.getMany(
ids,
true, // items
true, // payments
true, // customer
);
}
}
```
如此六個呼叫者只需表達「取得訂單詳情」：
```ts
const order = await orderLookup.getDetails(orderId);
const orders = await orderLookup.getManyDetails(orderIds);
```
這個設計的深度來自介面只暴露 `id`／`ids`，實作則吸收四個旗標、旗標順序及「details」的組成規則。若未來詳情增加其他關聯，只需修改此模組，六個呼叫者不變。
不應另外建立 `OrderRepositoryAdapter` 或可插拔 provider 介面；目前沒有第二種實作，這類 adapter seam 只會增加間接層。若 `OrderLookup` 也沒有替身或多實作需求，甚至可只匯出具體類別，將真正需要穩定的 `getDetails`／`getManyDetails` API 視為介面，而不額外宣告 TypeScript `interface`。
已載入 Skill +2023 tokens · 60110 ms
## 審查
### Module 與 interface
目前 `OrderLookup` 是一個淺 module：
- interface 暴露 `includeItems`、`includePayments`、`includeCustomer`，要求呼叫者理解 Repository 的載入機制。
- implementation 只原樣轉傳參數，沒有封裝業務語意。
- 「訂單詳情」這個真正的概念沒有進入 interface，反而散落成六處布林值組合。
- 布林參數在呼叫點也缺乏可讀性，例如 `getById(id, true, true, true)` 無法直接表達意圖。
這裡的 interface 不只包含 TypeScript 型別，還包含呼叫者必須知道「哪些旗標組合才構成完整訂單詳情」這項隱含規則。
### Depth
目前 interface 的複雜度幾乎等於 implementation 的複雜度：呼叫者指定載入策略，`OrderLookup` 只負責轉送。因此 depth 很低。
加深 module 的方向不是增加方法或設定物件，而是把穩定的業務語意藏進 implementation：
> 呼叫者要求「訂單詳情」；module 決定這代表 items、payments 與 customer。
### Leverage
目前六個呼叫者仍各自承擔相同知識，因此 `OrderLookup` 幾乎沒有提供 leverage。若改為語意化 interface：
```ts
orderDetails.getById(id)
```
每個呼叫者只需學會「取得訂單詳情」，不再需要理解三個 include 參數。一次 implementation 可以服務六個呼叫點及其測試。
### Locality
目前規則散落在六個呼叫者：
```ts
getById(id, true, true, true)
```
如果「訂單詳情」日後還要包含其他資料，就必須搜尋並修改所有呼叫者，也容易漏改。
把組合集中到 `OrderDetailsLookup` 後，規則、修改與驗證都集中在一處。這提升 locality：改一次，所有呼叫者一致生效。
### Deletion test
刪除目前的 `OrderLookup` 後，呼叫者只需改成直接呼叫 Repository 並傳入相同旗標；幾乎沒有額外複雜度重新出現。這表示目前 module 沒有真正封裝知識，接近純 pass-through。
刪除改善後的 `OrderDetailsLookup`，則「訂單詳情包含哪些關聯資料」的規則會重新散回六個呼叫者。這表示新 module 確實在集中並隱藏複雜度，能通過 deletion test。
## 更深的 interface 草案
單筆與多筆具有不同回傳形狀，保留兩個方法是合理的；移除載入旗標，讓名稱直接表達用例：
```ts
type OrderDetails = Order & {
items: readonly OrderItem[];
payments: readonly Payment[];
customer: Customer;
};
class OrderDetailsLookup {
constructor(private readonly repository: OrderRepository) {}
getById(id: OrderId): Promise<OrderDetails | undefined> {
return this.repository.getById(
id,
true, // includeItems
true, // includePayments
true, // includeCustomer
);
}
getMany(ids: readonly OrderId[]): Promise<readonly OrderDetails[]> {
return this.repository.getMany(
ids,
true, // includeItems
true, // includePayments
true, // includeCustomer
);
}
}
```
其公開 interface 為：
```ts
getById(id: OrderId): Promise<OrderDetails | undefined>
getMany(ids: readonly OrderId[]): Promise<readonly OrderDetails[]>
```
仍需依既有行為確認 `getMany` 的順序、重複 ID 與缺失 ID 規則；這些也屬於 interface，應明確記錄，而不是留給呼叫者猜測。
不需要新增 `IOrderDetailsLookup`、Repository wrapper 或其他 adapter seam。`OrderDetailsLookup` 可以是直接使用現有具體 Repository 的 module；等到確實出現第二種 implementation，再考慮建立 adapter seam。