Golang - 셰프와 웨이터가 단일 책임 원칙을 가르치는 방법

Golang에 초점을 맞춘 SOLID 원칙 시리즈의 첫 번째 기사에 오신 것을 환영합니다! 이 시리즈에서는 각 SOLID 설계 원칙을 분석하여 유지 관리 및 확장성이 더욱 뛰어난 Go 애플리케이션을 만드는 방법을 안내합니다. 우리는 단일 책임 원칙(SRP)부터 시작합니다. 이는 각 모듈이 단일 작업을 처리하도록 보장하여 깔끔한 코드를 강조하는 초석 개념입니다. ?

---

?️ 단일 책임 원칙 이해

단일 책임 원칙은 다음을 지시합니다.

클래스, 모듈, 함수를 변경해야 하는 이유는 단 하나여야 합니다.

기본적으로 각 구성요소는 하나의 책임에 집중해야 합니다. 멀티태스킹 코드는 오류 없이 유지 관리하고 확장하기가 어려워집니다. SRP를 준수하면 모듈성, 재사용성 및 테스트 가능성이 향상됩니다.

?‍? 실제 SRP 예: 셰프와 웨이터

붐비는 식당을 생각해 보세요. 고객 만족을 보장하는 두 가지 주요 역할:

• 셰프: 음식 준비에만 전념합니다.
• 웨이터: 주문을 관리하고 음식을 서빙하며 고객 요구 사항을 충족합니다.

한 사람이 두 역할을 모두 수행한다고 상상해 보세요. 주문을 받기 위해 요리를 잠시 멈추는 셰프는 다음과 같이 합니다.

• 느린 서비스.
• 음식 준비를 늦추세요.
• 오류 가능성이 높아집니다.

이 시나리오는 비효율적입니다. 한 사람이 관련 없는 일을 하다가 혼란이 옵니다.

레스토랑 환경에 SRP 적용

단일 책임 원칙 준수:

• 셰프가 음식을 직접 준비합니다.
• 웨이터는 주문과 고객 서비스를 전담 관리합니다.

이러한 분리를 통해 각 개인은 자신의 특정 역할을 탁월하게 수행할 수 있으므로 더욱 효율적이고 긍정적인 식사 경험을 얻을 수 있습니다. ?✨

? 소프트웨어 개발의 SRP

레스토랑의 예와 유사하게 코드는 하나의 책임만 처리하도록 클래스와 함수를 구성해야 합니다. 이를 통해 유지 관리 가능성이 향상되고, 변경이 가속화되며, 오류가 최소화됩니다.

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을 독립적으로 테스트할 수 있습니다.
• 간편한 유지 관리: 영수증 형식 변경은 결제 처리에 영향을 미치지 않습니다.

❓ SRP 적용 시기

다음과 같은 위반 사항을 식별합니다.

• 관련되지 않은 작업을 수행하는 함수 또는 구조체
• 문제가 혼합된 모듈(예: 비즈니스 로직 및 I/O).

✨결론

단일 책임 원칙은 코드 이해, 유지 관리 및 확장을 단순화합니다. 이것은 시작에 불과합니다! 이 시리즈의 다음 게시물에서는 SOLID의 "O"인 개방/폐쇄 원칙을 살펴봅니다.

중요한 OOP 기술인 종속성 주입에 대한 이전 게시물을 살펴볼 수도 있습니다.

즐거운 코딩하세요! ?

---

향후 게시물에 대한 업데이트를 받으려면 저를 팔로우하세요.

• 링크드인
• 깃허브
• 트위터/X

위 내용은 Golang - 셰프와 웨이터가 단일 책임 원칙을 가르치는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!