Tomu's Blog
0%

讀書筆記｜Clean Architecture｜Part 2. Programming Paradigms

Posted on Edited on In

之前參加的讀書會選書，當時讀書會進行到後期的時候，參與的大家都對這本書有類似的反饋：書中敘述的內容因為沒有實例佐證所以有些內容較無法想像。那時候我認為等開發經驗多累積一點再回來看這本書應該會有較深的感受，再加上書中前面的內容其實沒有上面提到的問題，個人覺得對初探架構的自己來說是有幫助的，因此打算至少整理一下到 SOLID Principles 前的讀書筆記。

本文所有圖片和程式碼都來自原書內容。

What is a Programming Paradigm? (Chapter 3)

書中提到的三種 Paradigm 如下：

  • Structured Programming
    • 用常見的 if/then/else, do/while/until (結構化)，限制 goto (跳轉)。
    • 限制程式控制權的直接轉移 (goto)。
  • Object-Oriented Programming
    • 利用 class 取代 Function pointer 來達成 Polymorphism。
    • 限制程式控制權的間接轉移 (Pointers to functions)。
  • Functional Programming
    • 核心: 符號的不可變性。
    • 限制 Assignment statement (在很嚴苛的情況下才能達成)。

參考上面條列的內容可以看出，在本書中 Programming paradigm 就是限制我們什麼不能做的規範。書中描述如下：

Each (paradigms) imposes some kind of extra discipline that is negative in its intent. The paradigms tell us what not to do, more than they tell us what to do.

我想大家看到這邊可能會有一點疑問：這些 Paradigm 和本書的重點 Architecture 有什麼關係？ 主要是隨著軟體開發的發展，大家漸漸明白什麼事情不能做，才容易讓軟體有好的架構。

接下來我會對這三種 Paradigm 做更詳細的介紹。

Structured Programming (Chapter 4)

由於大部分人開始學習程式語言應該都是從 Structured programming 開始，因此這個章節蠻好理解的。

章節的前半段主要介紹了在早期 goto statement 被廣泛使用的時代，Edsger Wybe Dijkstra 將除了 Simple selection (if/then/else) 和 Iteration control structures (do/while) 等情境下使用的 goto Statement 都視為 Harmful。主要原因是這類 goto 的使用會造成一個系統沒有辦法被遞迴拆成更小的 Provable unit 來證明一段程式的正確性。

不過照 Dijkstra 的理想來將每段程式都用數學去證明正確性需要花費太多資源，並不現實，因此後來發展成用較科學的方式來證明行為的正確性。書中描述如下：

Structured programming forces us to recursively decompose a program into a set of small provable functions. We can then use tests to try to prove those small provable functions incorrect. If such tests fail to prove incorrectness, then we deem the functions to be correct enough for our purposes.

以實務的角度來看其實就是寫 Test 或請 QA 跑 Checklist，只要能順利通過，我們就能信任產品至少在已知範圍內行為是正確的。

以 Architecture 的角度來說，Structured programming 提供了將不論是小小的 Function 或較大的 Component 進一步拆分 Modules, Components, Services 的能力，也更方便進行測試。

Object-Oriented Programming (Chapter 5)

What is OO?

在開始了解物件導向程式與 Architecture 的關係之前，我們需要先了解物件導向是什麼：

  • The combination of data and function.
  • A way to model the real world.
  • Three magic words
    • Encapsulation
    • Inheritance
    • Polymorphism

前兩者的敘述或是不夠貼切，或是有些空泛，書中以第三種定義來進一步延伸討論。

Encapsulation

因為藉由 OO 提供的 class，其 private/public members，我們能輕易做到決定一個物件中的哪些部分要隱藏，哪些部分則能開成介面讓外部知道，所以封裝常常被視為 OO 的一環。不過這其實並非 OO 獨有的特性，像是在 C 中，我們可以在 Header file 開出介面，並將實作細節藏在 .c 檔中 (Implementation file)。

C++ 反而稍微破壞了封裝這個特性，因為 Compiler 會要求 class 的 Member 在 Header file 中 Declare，在這種情況下即使用 private 來限制對這些 Member 的存取，但對使用的 Client 來說他還是因此知道了 class 中的資訊。更不用說像是 Java/C# 這些 OO 語言是完全將 Declaration 和 Implementation 混合在相同的檔案中的。

Note: 應該可以透過 Pimpl idiom 來完成 header file 中實作細節的分離，不過就還需要再多包一層 Inner class。

因此，很難說封裝是 OO 的必要條件。

Inheritance

和封裝不同，OO 的確讓繼承更為輕易，不過其實非 OO 語言也能做到繼承，以 C 為例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// 限於篇幅，沒有將所有 Implementation 的部分放上來

// point.h
struct Point;
double distance (struct Point *p1, struct Point *p2);

// point.c
struct Point {
    double x,y;
};

// namedPoint.h
struct NamedPoint;
struct NamedPoint* makeNamedPoint(double x, double y, char* name);

// namedPoint.c
struct NamedPoint {
    double x,y;
    char* name;
};

// main.c
int main(int ac, char** av) {
    struct NamedPoint* origin = makeNamedPoint(0.0, 0.0, "origin");
    struct NamedPoint* upperRight = makeNamedPoint (1.0, 1.0, "upperRight");
 
    double dist = distance(
        (struct Point*) origin, 
        (struct Point*) upperRight)
    );
}

可以看到上面的 code 中，由於我們還是可以用比較 tricky 的方式，將 NamedPoint cast 為 Point，不過如果使用 OO 語言，就不需要顯式轉型了，因此 OO 確實為繼承帶來了便利性。

Polymorphism

與封裝、繼承類似，其實在 OO 語言之前的語言也能實現多型，我們可以用 C 的 getchar 來為例，getchar 會從 STDIN 讀取資料，但 STDIN 是哪個 IO device？ 同理，putchar 中的 STDOUT 是哪個 IO device？ 書中提到：

The UNIX operating system requires that every IO device driver provide five standard functions: open, close, read, write, and seek.

也就是說 UNIX OS 要求 IO device driver 要實作 File 這個 struct (介面)：

1
2
3
4
5
6
7
struct FILE {
    void (*open)(char* name, int mode);
    void (*close)();
    int (*read)();
    void (*write)(char);
    void (*seek)(long index, int mode);
}

而對 getchar 來說，他其實只是 Call driver 實作的介面 (FILE 中的 read)，而並不在意實作的細節：

1
2
3
4
5
extern struct FILE* STDIN;

int getchar() {
    return STDIN->read();
}

不過如上述使用 Pointers to functions 來達成的多型是危險的，不論是實作者或是呼叫者都需要遵守同樣的 Convention。而對於 OO 語言來說，多型的達成變得更加便利且安全 (只需要透過如 virtual keyword 就能簡單做到，也不需要在意其背後如 vtable 的實作細節)。

不過多型對 Architecture 來說很重要嗎？我們回到上面提到的：對 getchar 來說，他其實只是 Call driver 實作的介面，而並不在意實作的細節。即使換了新的 IO device，只要 Driver 也有實作 FILE 中的 read，getchar 也不需要做任何的改動。換言之，IO device 可以被視為 getchar 的一個 Plugin。

因此多型能讓 High-level functions (getchar) 不再相依於 Mid/Low-level functions (Driver 對read 的實作)，而是相依於一個 Interface (FILE 中的 read)；與此同時 IO device 也需相依於 FILE 才知道需要實作哪些介面 (read) 提供給上層使用。上述現象讓 Dependency 變成：

graph LR;
    getchar --> read["FILE->read"]
    Driver --> read

這個現象與一般來說 High-level 直接相依 low-level 的關係不同，也因此被稱為 Dependency Inversion。而這也讓 Software architect 有能力控制系統中各 Unit 的相依性而不限於 Flow of control。舉例來說我們可以讓 UI 和 Database 之間互不相依，而是都相依於 Business Rules：

graph LR;
    UI --> Business["Business Rules"]
    Database --> Business

也因此上面三個部份可以各自被視為獨立的 Component，如果某個 Component source code 有改動，只需要重新 Deploy 這個 Component 就可以了，也即是 Independent deployability，而這通常也意味著 Independent developability。

Functional Programming (Chapter 6)

Structured vs Functional

首先我們來比較一下之前介紹的 Structured Programming 與 Functional Programming，以下實作一個 function 去印出 1 到 25 的平方：

  • Java (SP) 
    1
    2
    3
    4
    5
    6
    public class Squint {
         public static void main(String args[]) {
            for (int i=0; i<25; i++)
                System.out.println(i*i);
            }
    }
  • Clojure (FP) 
    1
    2
    3
    4
    (println ;___________________ Print
        (take 25 ;_________________ the first 25
            (map (fn [x] (* x x)) ;__ squares
                (range)))) ;___________ of Integers

在 Clojure 的 code 中，println, take, map 和 range 都是 function。可以觀察到 Java 的 code 中有用到一個變數 i 來控制 Loop，但 Clojure 的 code 中沒有這種變數，這也是這個章節中最關注的 FP 特性：

Variables in functional languages do not vary.

Immutablity and Architecture

之所以 Architect 需要考慮變數是否 Mutable，是因為所有的 Race conditions, Deadlock conditions 和 Concurrent update problems 都和 Mutable variable 有關。換言之，一旦可以保證 Immutablity，就不需要擔心 Concurrency applications 可能遇到的上述問題。不過實務上資源是有限的，要讓整個 Application 都做到符合這個特性不太可行，通常需要作一些妥協。

比較常見的方式是將 Application 拆成 Mutable 和 Immutable 兩種 Component，如下圖：

note-arch-02-segregation

Immutable component 中不會對其狀態/變數進行修改，也因此 Architect 應該要努力讓大部分的邏輯都歸於這類 Component 中。至於 Mutable component 則會對其狀態/變數進行修改，也因此常會透過如 Transactional memory 的概念來保護其可變的狀態/變數。

Example: Event Sourcing

雖然上面提到實務上需要作一些妥協，不過隨著 Storage 和 Processor 的進步，能做到 Immutable state 的比重也會越來越多，書中以銀行帳戶餘額為例來介紹這樣的 Application：

  • 不去紀錄客戶帳戶餘額為多少 (State)，而是將所有的 Transaction log 記錄下來。
  • 有人想要查餘額的時候，就將他全部的 Transaction 都撈出來，然後從第一筆加總到最後即可得知結果。

這就是 Event Sourcing 的概念，顯然在這種概念下設計的 Application 以 CRUD 的角度來看只會有 CR commands，不需要 Mutable variable，也不會有任何 Concurrent update 的問題。

不過隨著時間過去，Transaction Log 的數量會不斷增長，Storage 的需求和查餘額時需要的處理時間都會不斷上升，也因此理論上需要無限的資源才能讓這種設計可行，但這種設計還是有一些可能的使用情境，如下：

  • Application lifetime 有限，或許有限的資源即可滿足。
  • 還是保留一點 UD：比方說每天在半夜統整當天的 Transaction，因此查餘額只需要對當天的 Transaction 加總就好了。

Things to Remember

  • To the software architect: OO is the ability, through the use of polymorphism, to gain absolute control over every source code dependency in the system.

  • Plugin architecture: The low-level details are relegated to plugin modules that can be deployed and developed independently from high-level policies.

  • With infinite storage and processor power, we can make our applications entirely immutable (entirely functional).

  • Paradigms has taken something away from us.

What we have learned over the last half-century is what not to do.