如何使用 Closure 達成 Encapsulation ?

封裝 是 OOP 三個重要的特色之一，也由於 封裝 ，才導致了 多型 ，而 繼承 則是實現多型的手段 ( 里氏替換原則 )。事實上 FP 也能完美實現 封裝 ，關鍵就在於 Closure。

我們分別來看看 TypeScript、ReasonML 與 F# 如何以 Clsoure 達成 封裝 。

Version

TypeScript 2.8

ReasonML 3.1.0

F# 4.1

OOP 封裝

以 OOP 最經典的 Strategy Pattern 為例，我們將各種 strategy 封裝在 context 內，讓 client 與 strategy 解耦合。

interface Strategy {
  execute(x: number, y: number): number;
}

class Context {
  constructor(private strategy: Strategy) {
  }

  request(x: number, y:number): number {
    return this.strategy.execute(x, y);
  }
}

let context = new Context(new class implements Strategy {
  execute(x: number, y: number): number {
    return x + y;
  }
});

let result = context.request(1, 1);
console.log(result);
// 2

第 1 行

interface Strategy {
  execute(x: number, y: number): number;
}

訂出 strategy 的 class interface。

第 5 行

class Context {
  constructor(private strategy: Strategy) {
  }

  request(x: number, y:number): number {
    return this.strategy.execute(x, y);
  }
}

Context class 負責將 strategy 封裝在 field，對於 client 來說只認得 Context.request() ，將 client 與 strategy 解耦合。

14 行

let context = new Context(new class implements Strategy {
  execute(x: number, y: number): number {
    return x + y;
  }
});

Client 在建立 Context 物件時，順便將 strategy 傳入，由於只使用一次，可以使用 anonymous class。

20 行

let result = context.request(1, 1);
console.log(result);

Client 實際執行的是 Context.request() ，由於已經將 strategy object 封裝在 Context 的 field 內，因此 client 已經跟 strategy 解耦合。

FP 封裝

TypeScript

TypeScript 除了支援完整 OOP，也支援 FP。

interface Strategy {
  (x: number, y: number): number;
}

let context = (strategy: Strategy) => (x, y) => strategy(x, y);
let request = context((x, y) => x + y);

let result = request(1, 1);
console.log(result);
// 2

第 1 行

interface Strategy {
  (x: number, y: number): number;
}

將 strategy 的 interface 由 class interface 改成 function interface。

第 5 行

let context = (strategy: Strategy) => (x, y) => strategy(x, y);

將 Context class 退化成 context() function，class contructor 則退化成 function parameter，strategy function 依然要遵守 function interface。

回傳為新的 function，此時 strategy function 將以 Closure 形式保留在新的 function 內，也因為 Closure，使得 strategy function 被封裝在新的 function 內。

第 6 行

let request = context((x, y) => x + y);

由 context() 傳入 strategy function，以 Arrow Function 形式表達，而 request 為一 function，此時 strategy function 已經被封裝在 request() 內。

第 9 行

let result = request(1, 1);
console.log(result);

Client 實際執行的是 request() ，由於已經將 strategy function 封裝在 request() ，因此 client 已經跟 strategy function 解耦合。

ReasonML

let context = (strategy, x, y) => strategy(x, y);
let request = context((x, y) =>  x + y);

let result = request(1, 1);
Js.log(result);
// 2

第 1 行

let context = (strategy, x, y) => strategy(x, y);

因為 ReasonML 支援 Partial Application Function，因此可以將 context() 與 request() 合一，若只提供 strategy parameter，回傳的就是 strategy function。

第 2 行

let request = context((x, y) =>  x + y);

由 context() function 傳入 strategy function。

第 4 行

let result = request(1, 1);
Js.log(result);

Client 實際執行的是 request() ，由於已經將 strategy function 封裝在 request() ，因此 client 已經跟 strategy function 解耦合。

ReasonML 支援了目前 JavaScript 與 TypeScript 尚未支援的 Partial Application Function，也因為有 Type Inference，所以也不需要 interface，因此 ReasonML 寫起來比 TypeScript 精簡

FSharp

let context strategy x y = strategy x y
let request = context (fun x y ->  x + y)

let result = request 1 1
printf "%d" result

F# 寫起來與 ReasonML 已經非常類似，就不再詳細討論，大抵就是 F# 不用 () 與 ; ，且 Lambda 使用 fun ，但 F# 支援 Partial Function Application 與 Type Inference 則與 ReasonML 一致。

Conclusion

• OOP 使用 constructor + field 將變化加以封裝；而 FP 亦可使用 Higher Order Function + Closure 將變化加以封裝
• 若以 FP 方式思考，無論使用 TypeScript、ReasonML 或 F#，寫法都已經相當接近，程式碼也比 OOP 精簡
• ReasonML 與 F# 支援 Partial Application Function 與 Type Inference，程式碼又會比 TypeScript 更加精簡