Go 中的組合優於繼承

設計軟體時，「組合優於繼承」原則通常會帶來更靈活、可維護的程式碼。 Go 以其獨特的物件導向設計方法，嚴重依賴組合而不是繼承。讓我們看看為什麼。

為什麼 Go 更喜歡組合

在傳統的 OOP 語言中，繼承允許一個類別從另一個類別繼承行為和屬性，但這可能會導致僵化的、難以更改的層次結構。 Go 完全避免繼承，而是鼓勵組合——透過組合更小的、集中的元件來建構類型。

行動中的作文

想像一下，我們正在為一家擁有不同類型員工的公司建模：有些是工程師，有些是經理，有些是實習生。我們不會創建複雜的類別層次結構，而是將特定行為定義為獨立類型，然後組合它們。

範例：Go 中的 Worker 行為

package main

import "fmt"

type Worker interface {
    Work()
}

type Payable struct {
    Salary int
}

func (p Payable) GetSalary() int {
    return p.Salary
}

type Manageable struct{}

func (m Manageable) Manage() {
    fmt.Println("Managing team")
}

type Engineer struct {
    Payable
}

func (e Engineer) Work() {
    fmt.Println("Engineering work being done")
}

type Manager struct {
    Payable
    Manageable
}

func (m Manager) Work() {
    fmt.Println("Managerial work being done")
}

這裡：

• 工程師和經理嵌入 Payable，給他們薪水。
• Manager 也嵌入了 Manageable，賦予他們團隊管理能力。
• 每種類型單獨實作 Work()，滿足 Worker 介面。

組合的好處

• 簡單性：每個行為都封裝在其結構中，使其易於擴展。
• 靈活性：可以在不破壞現有程式碼的情況下新增類型或行為。
• 可重用性：行為是模組化的，因此我們可以輕鬆地以不同的方式組合它們。

使用組合介面

在 Go 中，介面和組合協同工作，允許多態性而無需繼承。以下是我們如何使用單一函數處理多種工作類型：

func DescribeWorker(w Worker) {
    w.Work()
}

func main() {
    engineer := Engineer{Payable{Salary: 80000}}
    manager := Manager{Payable{Salary: 100000}, Manageable{}}
    DescribeWorker(engineer)
    DescribeWorker(manager)
}

Go 對組合而不是繼承的偏好不僅僅是一種語言怪癖——它鼓勵更乾淨、更模組化、能夠適應變化的程式碼。您可以獲得靈活、可重複使用的元件，而不是僵化的層次結構，從而使您的程式碼庫保持靈活且易於維護。

以上是Go 中的組合優於繼承的詳細內容。更多資訊請關注PHP中文網其他相關文章！