Adapter Pattern

※ 情境 : 當你希望使用某個類， 但是其介面與其他程式碼不相容時， 可以使用轉接器類。

Interface

1
2
3

type Charger interface {
	TypecCharge()
}

Template Method Pattern

※ 情境 : 當多個類的演算法除了一些細微不同之外，其他幾乎完全一樣時，可以使用樣板方法模式。但其後果就是，只要演算法發生變化，你就可能需要修改所有的類。

Interface

1
2
3
4
5
6

type SpendMoney interface {
	goToStore()
	buySomething()
	pay()
	goHome()
}

Strategy Pattern

※ 情境 : 當有許多僅在執行某些行為時略有不同的相似類時，可使用策略模式。

Interface

1
2
3

type Transportation interface {
	travel()
}

Abstract Factory Pattern

※ 情境 : 如果程式碼需要與多個不同系列的相關產品互動， 但是由於無法提前獲取相關資訊， 或者出於對未來擴展性的考慮， 你不希望程式碼基於產品的具體類進行建構， 在這種情況下， 你可以使用抽象工廠。

Interface

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

type Shirts interface {
	HasSleeves()
	SuitableFor()
}

type Pants interface {
	FullLength()
	SuitableFor()
}

type ClothesFactory interface {
	MakeShirts() Shirts
	MakePants() Pants
}

Factory Method Pattern

Define

1
2
3
4
5
6

type BeverageType string

const (
	tea    BeverageType = "tea"
	coffee BeverageType = "coffee"
)

Interface

1
2
3
4
5
6
7

type Beverage interface {
	GetSweetnessLevel() string
	SetSweetnessLevel(percent int)
	HasCaffeine() bool
	SetCaffeine(hasCaffeine bool)
	GetDescription() string
}

Decorator Pattern

※ 定義 : 可以動態地為物件附加額外的職責。使用裝飾器來擴展功能比使用繼承更有彈性。

FunctionType 定義一個函數類型

1

type FunctionType func(string) string

Message 函數返回一個基本的消息

1
2
3

func Message(name string) string {
    return "Hello, " + name
}

資料庫正規化 (1NF、2NF、3NF)

目的是為了降低資料的「重覆性」與避免「更新異常」的情況發生。

正規化層級 (每一層皆需符合前面層級的正規化) :

• 第一正規化 (1NF)
• 第二正規化 (2NF)
• 第三正規化 (3NF)
• BCNF 正規化
• 第四正規化 (4NF)
• 第五正規化 (5NF)

正規化步驟 :

EIP-4844

目前透過 rollup 鏈 (Arbitrum, Optimism) 解決可擴充性問題，不過由於底層 Layer-1 鏈的設計架構導致仍然過於昂貴和緩慢，因此做出以下更新 :

• 新增將區塊鏈網路劃分為不同的資料庫 (分片)，以增加以太坊交易的空間。
• 以太坊區塊容量從 50-100KB 增加至 1-2 MB，使 rollup 鏈的成本降低為 1/10 至 1/20。
• 「 blob-carrying transactions 」的空間也隨之增加，節點驗證器則採用 「資料可用性抽樣」 技術來隨機抽樣驗證，就無需實際下載所有資料，以降低節點負擔。

※ 資料可用性抽樣 原理 : 當一個節點收到一個新的區塊時，它不會立即下載整個區塊，而是先隨機抽樣區塊中的一部分數據，然後它會詢問網絡中的其他節點來驗證這部分數據的有效性，如果網絡中的大多數節點都確認這些數據是有效的，那麼這個節點就可以確定整個區塊的數據是可用的，然後再下載和驗證整個區塊。這種技術可以防止”壞節點“發送包含無效或不完整數據的區塊，並且可以在不需要下載和驗證整個區塊的情況下快速確定區塊數據的可用性，從而提高了區塊鏈的效率和可擴展性。 (此技術主要用於 PoS)

常見技巧 :

1. 使用檢視和純函數

   檢視函數和純函數是在智能合約中執行操作時不需要支付 gas 費用的函數。檢視函數是唯讀的函數，不會對智能合約狀態進行更改，而純函數是不會讀取或更改智能合約狀態的函數。

2. 避免迴圈

   在智能合約中使用迴圈會導致額外的 gas 費用。因此，盡可能避免使用迴圈。例如，可以使用 Solidity 的 map 和 array 類型來替代迴圈。

3. 使用事件

   在智能合約中使用事件可以使資料在智能合約和外部應用程式之間傳遞，而不需要支付額外的 gas 費用。

4. 避免不必要的儲存

   在智能合約中儲存資料會導致額外的 gas 費用。因此，盡可能避免儲存不必要的資料。例如，可以使用檢視函數來返回計算結果，而不需要將結果儲存在智能合約中。

5. 最佳化計算和演算法

   盡可能使用簡單的計算和演算法來減少 gas 費用。一些常見的最佳化技巧包括快取計算結果，避免使用昂貴的加密演算法，以及使用位運算子。

Software Development Life Cycle，簡稱SDLC

SDLC 的各個階段 :

1. 計劃階段：確定需求、制定計劃和預算等。
2. 分析階段：分析和評估需求，確定軟體功能、性能、使用者介面和資料庫等。
3. 設計階段：設計軟體架構、系統介面、資料庫和程式碼等。
4. 開發階段：根據設計檔案開發軟體，包括編寫程式碼、測試程式碼等。
5. 測試階段：測試程式的功能、性能、安全性等，發現和修復缺陷。
6. 部署階段：在目標系統中安裝、組態和部署軟體。
7. 維護階段：對軟體進行維護和支援，包括修改錯誤、改進軟體性能等。