封裝也有了新的方式

封裝 是 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 解耦合。

TypeScript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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 行

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

訂出 strategy 的 class interface。

第 5 行

1
2
3
4
5
6
7
8
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 行

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

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

20 行

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

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

FP 封裝


TypeScript

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

1
2
3
4
5
6
7
8
9
10
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 行

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

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

第 5 行

1
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 行

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

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

第 9 行

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

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

ReasonML

1
2
3
4
5
6
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 行

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

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

第 2 行

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

context() function 傳入 strategy function。

第 4 行

1
2
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

1
2
3
4
5
6
let context strategy x y = strategy x y
let request = context (fun x y -> x + y)

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

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 更加精簡