設計模式 on Wayne's blog | 偉恩的部落格 | 技術博客

關於領域驅動設計 (Domain-Driven-Design)

Fri, 31 Mar 2023 00:00:01 +0000

軟體的核心是他為使用者解決領域相關問題的能力。隨著許多如金融、電商、社交等行業提供的服務越來越強大，軟體需求的複雜度也跟著起飛。身為一名工程師已經不能單純只做好自己的螺絲釘就能完成任務。

大多時候，程式設計的重點並不在於使用哪個框架技術或優化幾個百分比，而是在於是否能忠實解決業務的需求。

Eric Evans 發明了領域驅動設計 (Domain-Driven Design ，之後簡稱 DDD) ，提倡開發人員也需要與領域專家合作以獲取足夠的業務知識 (business knowledge)，接著將領域知識與業務邏輯注入進程式碼模型之中，達成「程式即設計、設計即程式」的境界。

運用了這套模式，一來程式碼功能一目瞭然，二來可以有效保護我們的業務邏輯不被竄改，甚至可以適應未來業務邏輯的變化與成長。

DDD 最大的價值之一就是把將商業領域的知識映照到程式碼中，解放「程式歸程式，業務歸業務」的傳統思維，在過程中甚至可以打破商業團隊與工程團隊間的藩籬，甚至會讓人感覺到：

開發其實是一場學習的過程，程式碼只是過程的副產物。

DDD 是什麼？

介紹 DDD 是什麼之前，我們先定義領域 (Domain) 是什麼。廣泛來說， domain (knowledge) 是指「一塊知識的範圍」。實務上，就是指「你工作上所需的一切知識集合」，包含「問題」以及「解決方案」。

由此可見， DDD 是一種基於領域知識來解決複雜業務問題的軟體開發方法論。

它有以下三個重點：

跟領域專家 (domain expert) 密切合作來定義出 domain 的範圍及相關解決的方案。
切分領域出數個子領域，並專注在核心子領域。
透過一系列設計模式，將領域知識注入進程式模型 (model) 中。

用通用語言(Ubiquitous Language)溝通

現代軟體的複雜特性，沒有一個人或是團隊可以單獨掌握所有的知識細節，甚至連領域專家的理解都可能有所缺漏。為了要盡可能獲取知識的全貌，我們會將溝通所得到的知識提煉出來達成共識後，建立 Ubiquitous Language (通用語言)，減少溝通的成本。

在神話故事巴別塔中，上帝分化人類的語言讓他們彼此無法溝通以懲罰他們的自大。有趣的是，在應用 DDD 的過程，不同團隊藉由溝通形塑出 Ubiquitous Language ，讓彼此互相理解，進而開發正確的軟體。

例：開發與商業團隊交流後，發現其實系統需要的是訂單、商品與會員管理三個功能，並且規定大家要用 Ubiquitous Language 互相溝通。

整個過程可以參考這張圖：

兩大設計模式類別

與領域專家討論出 Ubiquitous Language 後，就可以開始套用 DDD 的各種設計模式，而這些模式大致上可以分為兩類：Strategic Design (戰略設計) 與 Tactical Design (戰術設計)。

Strategic Design 戰略設計：利用與領域專家溝通的結果，拆分問題成數個子領域後，定義解決方案(系統)的邊界與關係。
Tactical Design 戰術設計：又稱 Model-Driven Design，在 Strategic Design 的一個個解決方案邊界內，用一系列設計模式寫程式實踐業務邏輯。

簡單來說，Strategic Design 打嘴砲設計大架構與方向，Tactical Design 捲起袖口開始寫程式。

DDD 帶來的改變

說了很多抽象的概念後，讓我們來看看在實作上，應用了 DDD 的程式碼會帶來什麼樣的改變？

向貧血模式(Anemic Model)說不

開始前想先跟大家介紹一個有名的反模式：貧血模型 (Anemic Model)，這個反模式泛指那些只有 getter 與 setter 的 model。這些 model 缺乏行為能力，導致使用者每次都要自己組合出自己要的功能。

因此貧血模型看似什麼都可以透過資料設定去做到，但因為沒有具有行為敘述的 method function ，所以難以應用於複雜的操作中。總體而言能力十分受限，就像貧血一樣。

貧血模型用起來像在教小孩子一樣，一個指令一個動作還很容易忘掉；具有行為能力的模型則像跟大人溝通一樣，一次行動就能完成許多指令。

再舉個例子，相信很多人都知道快打旋風、小朋友齊打交等格鬥遊戲。遊戲中角色若是要發動招式，就需要透過組合按鍵如「上跳攻」、「上上下下左右左右 BA」等等。

沒有行為能力的程式模型，就像這段組合鍵的程式碼一樣：

1
2
3
4
5
6
7
8
9


Role person = new Person();
// 組合按鍵開始
person.up();
person.down();
person.left();
person.right();
person.press('A');
person.press('B');
// 組合按鍵結束

但當我們了解業務邏輯後，就可以將這段程式封裝成有行為能力的 function：

1
2


Role person = new Person();
person.dragonFist();

這樣的優勢非常明顯，一來程式易懂好維護，二來要修改也很簡單。重點是程式碼從組合碎片式的資訊轉而關注程式的行為能力。

這時可能就會有人有疑問：「封裝的好處我懂，但如果濫用了程式碼一樣會亂啊！而且只是把程式封裝為什麼需要 DDD？」

配合業務語言封裝程式的行為

DDD 注重將業務語言注入程式模型之中，所以只會對重點業務行為進行封裝。如此一來，與其隨意封裝程式碼，DDD 將程式模型與業務邏輯綁在一起，不但可以緊隨業務的變化做修改，而且利用業務語言做封裝也解決了兩大程式難題之一：命名。

大家可以嘗試看看用業務行為為程式碼命名。最常見就是將原先 CRUD 的貧血命名法更改為充滿業務含義的命名方式。比如說一個 user 的 CRUD 操作可能就變成 register、getProfile、getActivityHistory、updateProfile、changePassword、deactivateAccount、deleteAccount 等等。

這種做法會在跨模型的情境下發揮更大的優勢，舉個咖啡廳的例子，假如一個正常流程包括點餐、製作、送餐，可以寫出以下程式碼：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


customer = new Customer('Bill');
order = Order.create(customer, 'Coffee');
staff = new Staff(9527);
cashier = new Cashier();

// 結帳
order.setStaff(staff);
staff.setCashier(cashier);
staff.setOrders(order);
cashier.addOrder(order);

// 泡咖啡
cup = new Cup();
staff.setCup();
cup.setFilterCone(new FilterCone());
cup.setCoffeeGround(new Coffee());
staff.brew(cup);
staff.wait();
staff.setFilterCone(null);

// 送餐
staff.setCoffeeTo(customer);
customer.setCoffee(order);

以上的程式碼可以明顯看出幾個問題：

所有屬性都可異動
難讀、業務意圖不明顯
難以應付未來的修改

導入 DDD 並與領域專家不斷溝通形成 Ubiquitous Language 後，讓我們修改一下程式碼：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


barista = new Barista(9527);
customer = new Customer('Bill');
order = customer.placeOrder(order);

// 處理結帳
barista.processPayment(order);

// 處理餐點
barista.make(order);

// 處理送餐
barista.serveOrderTo(order, customer);

修改後可以發現，程式的行為都十分貼近現時使用情境，讓即使不會寫程式碼的人都可以看懂了！

總結 DDD 的優缺點

使用 DDD 有以下優點：

促進跨團隊的溝通、理解領域知識。
專注在核心業務上
保護業務邏輯，不會因技術細節 (如 db 、框架、基礎設施)而影響。
開發時更靈活彈性、重用程式更方便，能夠面對未來的變化與成長。
更好的模組化 = 更容易測試 (完美搭配 TDD)。
出現 Bug 時更快找到原因 (已經將關注點分離，查出哪邊出問題很快)。
有利用拆分與設計 microservice (這也是最近幾年紅的原因)

不過也有以下幾點需注意：

較難快速建立產品 (戰術實作部分)
沒有領域專家會很難開頭 (新創需注意)
要導入溝通文化、學習成本高
對於高度科技(數學)專業的專案不一定合適

如果還不確定團隊是否該引入，可以參考這張 DDD 適合度計分卡：

FAQs

那不就代表我必須離開電腦先跟業務人員開一堆會嗎？

沒錯，乍聽之下增加了開發人員不少的負擔，但如果這節省了未來讀 spec 、改需求、維護、 debug 的時間，我相信仍是超值的。

我只是個小/新創團隊

很多人會把 DDD 看似繁重的設計當成敏捷開發的絆腳石。老實說，對於只是要開發 CRUD 的早期專案來說，是有點殺雞焉用牛刀。

但是 DDD 仍可以帶來幾項巨大的優勢，詳細可以參考這支影片 Turn your startup in a stayup with DDD — Marijn Huizendveld。

加深對於領域的理解
更加專注在核心領域上

另外新創也常遇到「但我們沒有領域專家啊」的問題。這部分上面提到的影片講者也有遇到，他的解決方法是實際與使用者合作獲取領域知識，再運用 DDD 的技術開發。

不過也是有社群的朋友分享即使是小專案，他也會利用 DDD 的部分 pattern 來快速建立模型。所以這部分其實見仁見智，對於 DDD 相當熟悉的人其實反而能在開發上更快速、正確的開發。

DDD 是萬能的嗎？

沒有什麼方法是銀子彈，只是各取所需罷了。 DDD 的強項在於解決複雜的業務邏輯以及拆分他們。因此搭上了 Microservice 的熱潮。很多人想引用 Microservice 卻不知如何正確拆分他們， DDD 此時提供了絕佳的切入點。

最後我必須強調， DDD 是一種設計方法，而設計本身沒有對錯，實作方法也有很多，不要只想著追求正確答案與完美設計，動手開始做才能做中學！

Ubiquitous Language 跟商業(業務)語言到底有什麼差別？

Ubiquitous Language 的意涵其實很簡單，可以視為一個被系統所需要且開發團隊與商業團隊都能理解的單字庫。以電商來說，「下訂單」這個詞兩邊都能理解且被系統需要，那個詞就可以被放進 Ubiquitous Language 中，而「顧客轉換率」、「公司營收」等商業用語若是與系統無關，就不在 Ubiquitous Language。

【Javascript】關於 Functional Programming 函數式編程

Mon, 27 Mar 2023 00:00:00 +0000

參考網站
 參考網站

在軟體工程開發的領域中，我們為了解決不同的問題，因此衍生出許多不同的程式設計(Programming paradigm)方式，這些設計方法彼此之間並沒有所謂的好壞、優劣，只有解決問題適合度高低的差異。

函數式編程(Functional Programming，以下簡稱 FP)是眾多程式設計(Programming Paradigm) 方式的其中一種，有別於老早就大紅大紫的物件導向編成(object-oriented Programming，OOP) 方式(OO還衍伸出許多設計模式)，FP 則是近年來較為熱門的程式設計方式。像是 React 這套 JavaScript 框架就是使用 FP 來開發程式，因此若想學習 React.js 勢必也要熟悉 FP 的基本概念，而 JavaScript 程式語言也需要符合 FP 的編程理念。本篇將以 JavaScript 作為出發，解釋 JavaScript 函數式編程的重要概念。

本篇皆以 JavaScript 為範例。

First-class & higher-order functions

First-class(一等公民)

我們可以想像成對待函式(Functions) 如同對待其他資料型別一樣。

例如：可以直接賦予值或者存至陣列中當作參數傳遞。

例如，我們可以宣告：

1

const a = 1;

1 的值也就指定給 a。

因此我們也可以直接將函式(Functions) 指定給任一變數：

1

const a = (x,y) => x * y;

a 也就變成 (x * y) Function 的變數，呼叫 a(2, 4) 則會返回值 8。

higher-order functions(高階函式)

在維基百科中高階函式至少會滿足下列其中一項條件：

可以將函式(至少一個)當成參數傳入另一個函式。
可以將函式當成另一個函式的回傳值。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


var add = function(x) {
 return function(y) {
 return x + y;
 };
};

var addFive = add(5);
var addTen = add(10);

addFive(2); // 7
addTen(2); // 12

由上述範例我們可以得知，add 函式接收參數 (x)，並且回傳一個函式 ( x + y ) 作為回傳值。

因此在宣告 addFive 變數時，同時給定 x = 5 至 add 函式，往後使用 addFive 變數(函式變數)皆會從 5 開始加減。

上述則是符合 higher-order functions 的例子，add 函式(Functions) 接收參數並且回傳一個函式(Functions) 作為回傳值。

函數柯里化文章可參考之前撰寫的(【Function Currying】Javascript 函數柯里化)[/2023-03-16/js-function-currying/]

Pure Functions

Pure Functions(純函式)，意指將相同的 input 丟入函式，永遠會回傳相同的 output 結果，而且在過程中完全沒有任何的副作用。此處的副作用通常意味著「避免狀態改變」、「避免資料改變」，我們可以想成不與函式區塊域(block) 以外的變數做互動(最典型的例子，修改全域變數的值)，或者不論函式以外做了什麼，函式(Functions) 內的運算依舊不受改變。換句話說，Pure Functions 擅於純運算，而不做其他事情(ex. 讀取外部資料)。

範例如下：

1
2
3
4
5
6
7
8
9


// slice: Pure Function
var arr = [1, 2, 3, 4, 5, 6];
arr.slice(0, 3); // output = [1, 2, 3], arr = [1, 2, 3, 4, 5, 6]
arr.slice(0, 3); // output = [1, 2, 3], arr = [1, 2, 3, 4, 5, 6]

// splice: not Pure Function
var arr = [1, 2, 3, 4, 5, 6];
arr.splice(0, 3); // output = [1, 2, 3], arr = [4, 5, 6]
arr.splice(0, 3); // output = [4, 5, 6], arr = []

在 Functional Programming 中，slice 函式(Functions) 就符合我們 Pure Functions 的規範，相同 input，永遠回傳相同 output 且無副作用。而 splice 函式(Functions) 則是每次呼叫，output 以及原始資料皆會不相同，因此不算是 Pure Functions。

副作用

以 JavaScript 為例，副作用還包括：

更改外部變數或者物件屬性(例如：全域變數、父類別範圍內的變數等)
寫入 console.log、檔案
觸發外部流程
呼叫任何有副作用的函式(Functions)

Declarative vs Imperative

函數式編程(Functional Programming) 屬於宣告式編程(Declarative Paradigm) 的一種。

宣告式編程(Declarative Paradigm)：較為抽象的程式碼，可以藉由自然語言直觀的理解該行程式碼想要達到什麼樣的結果。描述該在哪做什麼(what to do)以及資料流程(data flow)。
指令式編程(Imperative Paradigm)：程式碼具體表達需要做什麼來達到目標。描述該做什麼(how to do)以及流程控制(flow control)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


var a = [1, 2, 3, 4, 5];

// Declarative Programming
declarativeSquare = (arr) => arr.map((val) => val*val)
declarativeSquare(a); // [1, 4, 9, 16, 25]

// Imperative Programming
imperativeSquare = (arr) => {
 for (var i = 0; i < arr.length; i++) {
 arr[i] *= arr[i];
 }
 return arr;
}
imperativeSquare(a); // [1, 4, 9, 16, 25]

宣告式編程(Declarative Paradigm) 較依賴表達式(expression)，表達式是一個單純的運算過程，並且總是會返回值。屬於宣告式編程的程式語言有：HTML、SQL、LINQ。

指令式編程(Imperative Paradigm) 的程式碼經常使用程式語言基本的語句(statement)，例如：for、while、if、switch…等等。屬於指令式編程的程式語言有：C、JAVA。

總結

函數式編程(Functional Programming) 誕生了五十多年後，終於獲得程式開發者大量的關注，目前 ML 非常紅的 Python 以及前後端 JavaScript 等語言，對於函數式編程(Functional Programming) 的支持都很強。本篇文章整理 JavaScript 符合函數式編程(Functional Programming) 概念的幾個元素(First-class、higher-order functions、Pure Functions)，希望透過 JavaScript 的實例理解函數式編程所講述的核心理念為何。最後比較宣告式編程(Declarative Paradigm)以及指令式編程(Imperative Paradigm)，對自己過去在軟體開發這塊領域所學的做個整理，理清並梳理已有的知識。

物件導向的 Q&A - 以 Python 舉例

Tue, 21 Mar 2023 00:00:00 +0000

參考網站
 參考網站

物件導向

請問物件導向程式語言有哪些特點，能簡單說明給我聽嗎？

物件導向程式語言 (Object-Oriented Programming，OOP) 的特點有：

物件導向：OOP 程式語言是以物件 (Object) 為基礎建構程式，物件具有狀態 (state) 和行為 (behavior)。
繼承 (Inheritance)：OOP 程式語言允許一個類別 (class) 從另一個類別繼承屬性和行為。
多型 (Polymorphism)：OOP 程式語言允許物件在不同的情況下具有不同的行為。
封裝 (Encapsulation)：OOP 程式語言允許將物件的狀態和行為封裝在一起，保護物件內部狀態不被外界直接存取。
抽象 (Abstraction) ，OOP 程式語言將物件的實作細節與使用者分開，使用者只需要知道物件的公開介面而無需知道其實作。

請問物件具有狀態 (state) 和行為 (behavior)。這句話是什麼意思？能用 python 舉例嗎？

物件具有狀態 (state) 和行為 (behavior) 意思是物件具有兩種不同的特性，狀態代表物件的屬性，行為代表物件的方法。

舉例來說，若我們有一個類別叫做 Car，那麼這個類別可能有一些狀態屬性如 “color”、“speed”、“brand”，而行為可能有 “drive”、“brake”、“turn” 等方法。

用 python 程式碼來實現這個類別可能長得像下面這樣：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


class Car:
 def __init__(self, color, speed, brand):
 self.color = color
 self.speed = speed
 self.brand = brand

 def drive(self):
 self.speed += 10

 def brake(self):
 self.speed -= 10

 def turn(self, direction):
 print(f"The car is turning {direction}")

my_car = Car("red", 0, "Tesla")
my_car.drive()
my_car.turn("left")
print(my_car.speed) # 10

上面這個例子中，類別 Car 有三個狀態屬性 color、speed、brand 以及三個行為方法 drive()、brake()、turn()。

透過創建一個實體物件 my_car = Car("red", 0, "Tesla") 來使用這些方法及屬性。

請問你能用上面的 Car class 寫一個繼承的範例給我看嗎？

當然可以，我們可以創建一個新的類別來繼承 Car 類別，讓新類別繼承 Car 類別的屬性和方法。

例如我們可以創建一個新的類別 ElectricCar 繼承 Car 類別，並且在 ElectricCar 類別中加入新的屬性和方法。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


class ElectricCar(Car):
 def __init__(self, color, speed, brand, battery_size):
 super().__init__(color, speed, brand)
 self.battery_size = battery_size

 def charge(self):
 print("The electric car is charging...")

 def drive(self):
 if self.battery_size > 0:
 self.speed += 20
 self.battery_size -= 10
 else:
 print("The battery is empty, please charge the car.")

my_electric_car = ElectricCar("blue", 0, "Tesla", 100)
my_electric_car.drive()
my_electric_car.drive()
my_electric_car.drive()
print(my_electric_car.speed) # 60
print(my_electric_car.battery_size) # 70

在這個例子中，ElectricCar 類別繼承了 Car 類別的所有屬性和方法，並且定義了新的屬性 battery_size 和方法 charge()。

透過使用 super() 函式可以繼承 Car 類別的 init 方法。

使用 my_electric_car = ElectricCar("blue", 0, "Tesla", 100) 來創建實體物件，可以使用 ElectricCar 類別的新屬性及方法。

請問你能用上面的程式碼繼續舉例多型的用法給我看嗎？

當然可以，多型 (Polymorphism) 是指物件在不同的情況下具有不同的行續。一般來說我們可以使用繼承的類別來實現多型。

以上面程式碼為例，我們可以用 ElectricCar 類別繼承 Car 類別，並重新實現 drive 方法來實現多型的用法。

 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
32
33
34
35
36
37
38
39
40
41


class ElectricCar(Car):
 def __init__(self, color, speed, brand, battery_size):
 super().__init__(color, speed, brand)
 self.battery_size = battery_size

 def charge(self):
 print("The electric car is charging...")

 def drive(self):
 if self.battery_size > 0:
 self.speed += 20
 self.battery_size -= 10
 else:
 print("The battery is empty, please charge the car.")

class GasCar(Car):
 def __init__(self, color, speed, brand, gas_level):
 super().__init__(color, speed, brand)
 self.gas_level = gas_level

 def fill_gas(self):
 self.gas_level = 100

 def drive(self):
 if self.gas_level > 0:
 self.speed += 15
 self.gas_level -= 10
 else:
 print("The gas is empty, please fill the gas.")

my_electric_car = ElectricCar("blue", 0, "Tesla", 100)
my_gas_car = GasCar("black", 0, "Ford", 60)

def drive_car(car):
 car.drive()

drive_car(my_electric_car)
drive_car(my_gas_car)

print(my_electric_car.speed) # 20
print(my_gas_car.speed) # 15

在這個例子中，我們在 ElectricCar 和 GasCar 類別中都重新實現了 drive 方法，並且在 drive_car 函數中只接受 Car 的類別，可以看到在 drive_car 函數中傳入不同類別的實體物件會執行不同的 drive 行為。

這就是多型的用法，可以讓同一個函數或方法支援多種類別的物件，而不需要為每一種類別都寫一個不同的函數或方法。這樣可以增加程式碼的彈性和可讀性。

我們可以在設計類別時統一實現某些方法，並讓類別可以自行選擇如何實現該方法，這樣就可以讓程式碼更具彈性和靈活性。

請問你能用上面的程式碼繼續舉例封裝的用法給我看嗎？

當然可以，封裝 (Encapsulation) 是指將物件的狀態和行為封裝在一起，保護物件內部狀態不被外界直接存取。

在 Python 中，我們可以使用 _ 或 __ 來表示私有變數和方法，這樣的變數和方法只能在類別內部存取。

例如，我們可以把 ElectricCar 類別中的 battery_size 屬性改成私有變數：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


class ElectricCar(Car):
 def __init__(self, color, speed, brand, battery_size):
 super().__init__(color, speed, brand)
 self.__battery_size = battery_size

 def charge(self):
 print("The electric car is charging...")

 def drive(self):
 if self.__battery_size > 0:
 self.speed += 20
 self.__battery_size -= 10
 else:
 print("The battery is empty, please charge the car.")

 def get_battery_size(self):
 return self.__battery_size

my_electric_car = ElectricCar("blue", 0, "Tesla", 100)
print(my_electric_car.get_battery_size()) #100

在這個例子中，ElectricCar 類別的 battery_size 屬性被定義為私有變數，只能在類別內部存取。如果外部直接存取該變數的話會產生錯誤。

而我們可以使用私有變數所對應的公有方法 get_battery_size() 來存取私有變數。這樣可以保護類別內部狀態不被外部直接存取，也可以通過公有方法給外部提供適當的存取權限。

你說在 Python 中，我們可以使用 _ 或 __ 來表示私有變數和方法，請問 _ 跟 __ 差在哪裡？

用一個底線 _ 表示私有變數和方法並不會真正的阻止外部存取，只是約定俗成的寫法。
而使用兩個底線 __ 來表示私有變數和方法會真正的封裝，阻止外部存取，並且子類別也無法存取，更能保證封裝性。

請問你能用上面的程式碼繼續舉例抽象的用法給我看嗎？

可以，以下是之前提到的 Car、ElectricCar、GasCar 程式碼使用抽象類別和抽象方法的寫法：

 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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


from abc import ABC, abstractmethod

class Car(ABC):
 def __init__(self):
 self.__year_model = 0
 self.__make = ""
 self.__speed = 0

 @abstractmethod
 def drive(self):
 pass

class ElectricCar(Car):
 def __init__(self):
 super().__init__()
 self.__battery_type = ""

 def set_battery_type(self, battery_type):
 self.__battery_type = battery_type

 def get_battery_type(self):
 return self.__battery_type

 def drive(self):
 print("Electric car is driving.")

class GasCar(Car):
 def __init__(self):
 super().__init__()
 self.__fuel_type = ""

 def set_fuel_type(self, fuel_type):
 self.__fuel_type = fuel_type

 def get_fuel_type(self):
 return self.__fuel_type

 def drive(self):
 print("Gas car is driving.")

#create object
car = ElectricCar()
car.drive()

car = GasCar()
car.drive()

在這個範例中，Car 類別是一個抽象類別，它定義了一個抽象方法 drive()。ElectricCar 和 GasCar 類別都繼承自 Car 類別，並實現了 drive() 方法。

這樣的設計可以達到封裝的目的，同時也可以達到多型的目的。並且因為 Car 類別是抽象類別，所以不能直接建立 Car 類別的物件，只能用它的子類別來建立物件。

有了繼承的特點為何還需要抽象？感覺不出這兩者有何差別？

繼承的作用是讓子類別可以繼承父類別的屬性和方法，使得子類別可以共用父類別的程式碼，達到代碼重用的目的。這樣可以讓程式碼更簡潔，並且可以讓子類別擁有父類別的特徵。

而抽象則是讓類別有共同的特徵和行為，抽象類別不能被實例化，而是用來被其他類別繼承。抽象類別中可以定義抽象方法(abstract method)和普通方法，抽象方法只有定義，沒有實現。在子類別中必須實現抽象方法。這樣可以確保所有子類別都有相同的行為，但實現可能不同。

在車的例子中，我們可以用繼承的方式，讓 ElectricCar 和 GasCar 繼承 Car 的屬性，例如 make、model、year_model。而用抽象的方式，我們可以在父類別 Car 中定義一個 drive 方法，並在子類別中實現 drive 方法，這樣可以確保所有車子都有 drive 這個行為。

實際業務上來說，何時會想用繼承何時會想用抽象？

實際業務上，繼承和抽象會根據實際需求而使用。

繼承：

要繼承另一個類別的特徵和行為時，就可以使用繼承。例如，你有一個車類別，並且你需要創建一個電動車和汽油車類別，這兩個類別都有許多相同的特徵和行為，那麼你可以使用繼承，將車類別的特徵和行為繼承到電動車和汽油車類別中。

抽象：

當你有一些類別需要共用同一個介面或行為時，就可以使用抽象。例如，你有一個車類別，並且你需要創建多種不同類型的車，例如電動車、汽油車、柴油車等，這些車都需要有 drive 這個行為，那麼你可以使用抽象類別來定義一個 drive 方法，並在電動車、汽油車、柴油車等類別中實現 drive 方法，這樣就可以確保所有車都有 drive 這個行為。

總結來說，繼承是用來繼承父類別的特徵和行為，而抽象則是用來確保類別具有共同的特徵和行為。

請問你說的特徵具體來說是指什麼東西？

特徵是指類別所具有的屬性和行為，包括資料和函式。

屬性是指類別中的變數，它們用來儲存類別中的資料。例如在之前的例子中，Car 類別中的屬性有 make、model、year_model。

而行為是指類別中的函式，它們用來定義類別的動作。例如在之前的例子中，Car 類別中的行為有 drive、get_make、get_model 等。

這些屬性和行為就是類別的特徵。

請問物件導向為何叫做物件導向？

物件導向程式語言之所以叫做物件導向是因為它重視物件 (Object) 這個概念。在物件導向程式語言中，程式設計師可以使用類別 (Class) 來定義物件的共性，並使用物件來實例化類別。

物件具有狀態 (state) 和行為 (behavior)，並且可以互相之間進行溝通和互動。透過物件導向程式設計，可以更加形象地模擬實際世界中的事物，並且更加容易維護和擴展程式碼。

【WebAPI】分層設計模式 - 三層式架構

Fri, 24 Feb 2023 00:00:00 +0000

參考網站
 參考網站
 參考網站
 參考網站
 參考網站

軟體分層設計模式是我這幾年專案必會使用的架構，它的效益在多人團隊分工上有極大的效益，且能有效專注修改區域，提高共用性。

三層式架構 (Three-Tier) 是很常見的架構，可以應用在實體機器架構上，也可以應用在邏輯架構上，可以按照實體與邏輯上去進行區分。

為甚麼要分層？

如果程式全部一條龍寫到底，後續會產生很多問題，難以維護、難以閱讀、更甚至是萬一人家要接手你的程式碼，這時候改Ａ壞Ｂ，耦合度過高的情況下，你只能祈禱接手的人不知道你住哪…

這種情況下只有自己寫可能還好，那如果需要跟人合作呢？

大家可能容易出現重複的 Code，也難以說明誰該負責寫哪部分。

這時候有一個好的架構，就很重要了，分層設計時，遵循了面向介面設計的思想，那麼這種向下的依賴也應該是一種弱依賴關係。因而在不改變介面定義的前提下，理想的分層式架構，應該是一個支持可抽取、可替換的「抽屜」式架構。

WebAPI 的三層式架構

WebAPI 的三層式架構顧名思義，主要分為了三層：

Controller：控制層，作為接口。
Service：商業邏輯層，只要有關商業邏輯部分的處理全部放在這一層。
Repository：倉儲層，作為資料存儲的一層。
Common：共用層，作為存放各層會用到的相同東西。

他們之間的關係如下圖：

優缺點

優點
1、較好形成一個規範，可做為標準化流程。
2、提高重用性，透過分層將相同類型的程式碼放在一塊。
3、團體合作的時候，能夠分層進行；開發人員只需專注於自己開發的那一層即可。
4、具有好的開放性、可擴充性優點。
5、降低程式碼之間的依賴，每層溝通是透過介面。
6、提高系統安全性，因為使用者需要透過 Service 層才有機會與下一層 Repository 撈取資料。

缺點
1、增加了開發成本，傳統一個人負責寫到底；分層下需要多人進行合作。
2、調整程式可能會出現連動性；有的時候修改一個地方，會導致其他層也需要跟著調整。
3、相較於一條龍開發系統性能下降，原本程式可以直接透過 DB 撈取資料，現在需要透過中間層的轉介才能夠拿到。

Controller

在我們 WebAPI 中，Controller 就屬於『接口』，負責處理 Router，如常見的：Get、Post、Patch…等，都會是在這層負責接應相對應的路由。

Controller 接收的是 Parameter，輸出的是 ViewModel。

Service

在我們程式中最重要的就屬於『商業邏輯』了，這一層是會特別關注的一層；這邊大家可能會問，那商業邏輯是指哪些呢？

我自己認為最簡單分辨的方式，舉凡任何需要對資料特別處理的地方都會是放在這一層，如常見的：登入驗證、加減法運算、確認是否驗證成功…等。

Service 接收的是 InfoModel，輸出的是 Dto。

Repository

資料倉儲層，這層主要處理『有關資料串接』的部分，如：資料庫連接、下 SQL 取 Table 資料…等，都會是在 Repository 處理。

這邊有個特別的地方，如果我們程式需要透過別人的 API 取的資料回來做處理呢？

那與對方 API 串接的地方就會是 Repository，所以 Repository 是處理『有關資料串接』的地方，而這資料當然並不只限於從 DB 撈取的資料。

Repository 接收的是 Condition，輸出的是 DataModel。

Common

共用層相對單純，存放各層間會用到的『共同』東西，最常見的例如：Enum…等，就會放在這一層。

常見問題

三層式架構與傳統 MVC 有甚麼不同呢？

傳統 MVC 分成，View(展示層)、Model(資料層)、Controller(控制層)，這邊與三層式架構最大的區別在於傳統 MVC 並沒有特別把『商業邏輯』抽出來；常會看到傳統 MVC 可能會把商業邏輯附加在 Controller，所以 MVC 與三層式架構是不同的。

各層間溝通一定要透過 Model 嗎？

這個答案就我個人使用的理解是，『不一定要透過 Model』，如果只是要回傳簡單的 bool 、或是一兩個參數，直接傳就可以了；那做成 Model 的用意呢？當然也是為了提高重用性，例如 ResultModel。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


public class ResultModel
{
 /// <summary>
 /// 結果
 /// </summary>
 public bool Result { get; set; }

 /// <summary>
 /// 提示訊息
 /// </summary>
 public string Message { get; set; }
}

雖然只有兩個變數，但還是把它包成了 Model ，因為有很多個地方會需要用到，當然就可以包起來給大家共同使用。

Service 層可以呼叫其他 Service 層的程式嗎？

可以，三層式架構的優點就是要提供重用性，當然如果相同的事情在其他地方已經有做過了，直接拿來使用，就不用做重複的事情。

Model 的名稱分了這麼多？不能直接一個通到底嗎？

這問題也是我一開始不太能夠理解的部分，如果是一個人寫程式的時候都會為了方便，就一個 Model 通到底吧；這時候肯定會有人問就算多人合作也可以啊？

真的可以嗎？

各層間的職責都不同，從 Reoisitory 取出來的資料丟給 Service 做處理，有可能不需要全部完整的資料回傳給 Controller，為了避免這種情況當然是分開會比較妥當，自己使用自己的 Model；多人合作的時候只需要定義說好相互要傳遞的參數就可以分層開發了，也不會因為一個 Model 而影響對方。

小結

當我是一個人開發的時候，分層設計真的感受不深，更多的是為何要弄得這麼複雜，但隨著工作團隊的擴展，多人合作開發的時候，分層設計就發揮出了它的價值，各個成員專注各自的層發開，不會被其他成員影響，當需要修改或擴充時，若是要改 UI，只需要異動展示層，若是新增商業邏輯則只需專注業務層，而是為要換第三方配合廠商或者更換資料庫，則只需專注在資料層去修改，而各層的物件又可以依不同情境做重用，不需重複開發，可謂好處多多。

效益：

適合多人團隊分工時不互相影響 (一條龍開發時感受不深)
分層專注，可以專注修改，不會牽一髮動全身

但真的能達到這樣的效益，其實還有一些必要前提：

物件設計須符合 SOLID 原則
各層依賴介面 (Interface)，不依賴實作
專案需導入 DI Framework，做到依賴注入，達成控制反轉 (IoC)
撰寫單元測試 (Unit Test) 保護每次修改
合理的設計各層職責物件，業務層更為重要