Golang - シェフとウェイターが単一責任の原則を教える方法-Golang-php.cn

Golang - シェフとウェイターが単一責任の原則を教える方法

Barbara Streisand

リリース： 2025-01-16 12:21:59

オリジナル

479 人が閲覧しました

Golang に焦点を当てた私の SOLID 原則シリーズの第 1 回へようこそ!このシリーズでは、それぞれの SOLID 設計原則を詳しく解説し、より保守性と拡張性の高い Go アプリケーションの作成に向けてガイドします。まず、単一責任原則 (SRP) から始めます。これは、各モジュールが単一のタスクを処理することを保証することにより、よりクリーンなコードを強調する基礎となる概念です。 ?

?️ 単一責任の原則を理解する

単一責任原則では次のように規定されています。

クラス、モジュール、または関数を変更する理由は 1 つだけである必要があります。

基本的に、各コンポーネントは 1 つの責任に集中する必要があります。マルチタスクコードは、エラーを発生させずに保守および拡張することが困難になります。 SRP に準拠すると、モジュール性、再利用性、テスト容易性が向上します。

Golang - How a Chef and Waiter Teach the Single Responsibility Principle

?‍? 現実世界の SRP の例: シェフとウェイター

忙しいレストランを考えてみましょう。顧客満足度を保証する 2 つの重要な役割:

シェフ: 食事の準備だけに集中します。
ウェイター: 注文を管理し、食事を提供し、顧客のニーズに対応します。

1 人が両方の役割を果たしていると想像してください。シェフは注文を受けるために調理を一時停止します:

サービスが遅いです。
食事の準備を遅らせます。
エラーの可能性が増加します。

このシナリオは非効率的です。 1 人が関係のないタスクをやりくりすると混乱が生じます。

レストラン設定での SRP の適用

単一責任原則に従います:

シェフのみが料理を準備します。
ウェイターは、注文と顧客サービスを単独で管理します。

この分離により、各個人がそれぞれの役割で優れた能力を発揮できるようになり、より効率的で前向きな食事体験が得られます。 ?✨

?ソフトウェア開発における SRP

レストランの例と同様に、コードは 1 つの責任のみを処理するクラスと関数を構造化する必要があります。これにより、保守性が向上し、変更が加速され、エラーが最小限に抑えられます。

Golang を使用した SRP の動作

SRP に違反すると、脆弱で管理不能なコードがどのように作成されるかを調べてみましょう。

❌ 例: SRP 違反

基本的なコーヒーショップの注文管理システムを考えてみましょう:

<code>package main

import "fmt"

// Order stores coffee order details.
type Order struct {
    CustomerName string
    CoffeeType   string
    Price        float64
}

// ProcessOrder handles multiple responsibilities.
func (o *Order) ProcessOrder() {
    // Handles payment processing
    fmt.Printf("Processing payment of $%.2f for %s\n", o.Price, o.CustomerName)

    // Prints receipt
    fmt.Printf("Receipt:\nCustomer: %s\nCoffee: %s\nAmount: $%.2f\n", o.CustomerName, o.CoffeeType, o.Price)
}

func main() {
    order := Order{CustomerName: "John Doe", CoffeeType: "Cappuccino", Price: 4.50}
    order.ProcessOrder()
}</code>

ログイン後にコピー

Order 構造体は、データの保存、支払い処理、領収書の印刷を処理しますが、これは明らかな SRP 違反です。側面を変更すると ProcessOrder に影響があり、保守性が妨げられます。

?️ SRP に準拠するためのリファクタリング

責任を個別のコンポーネントに分割しましょう:

<code>package main

import "fmt"

// Order stores coffee order details.
type Order struct {
    CustomerName string
    CoffeeType   string
    Price        float64
}

// ProcessOrder handles multiple responsibilities.
func (o *Order) ProcessOrder() {
    // Handles payment processing
    fmt.Printf("Processing payment of $%.2f for %s\n", o.Price, o.CustomerName)

    // Prints receipt
    fmt.Printf("Receipt:\nCustomer: %s\nCoffee: %s\nAmount: $%.2f\n", o.CustomerName, o.CoffeeType, o.Price)
}

func main() {
    order := Order{CustomerName: "John Doe", CoffeeType: "Cappuccino", Price: 4.50}
    order.ProcessOrder()
}</code>

ログイン後にコピー

? SRPのメリット

懸念の分離: Order はデータを保存します。 PaymentProcessor は支払いを処理します。 ReceiptPrinter は領収書を生成します。
強化されたテスト容易性: PaymentProcessor と ReceiptPrinter は個別にテストできます。
簡素化されたメンテナンス: 領収書の形式を変更しても、支払い処理には影響しません。