SOLID 원칙 - Python의 실제 예제를 사용하여 설명

SOLID 원칙(이미지 제공: FreeCodeCamp)

SOLID는 개발자가 유지 관리하기 쉽고 이해하기 쉽고 유연한 소프트웨어를 만드는 데 도움이 되는 5가지 디자인 원칙을 의미하는 약어입니다. 관련 사례를 통해 하나씩 살펴보겠습니다.

1. S - 단일 책임 원칙(SRP)

정의: 클래스를 변경해야 하는 이유는 단 하나여야 합니다. 즉, 클래스에는 하나의 작업이나 책임만 있어야 합니다.

설명: 이메일 보내기와 결제 처리 등 두 가지 다른 작업을 결합한 도구가 있다고 상상해 보세요. 단일 수업에서 두 ​​작업을 모두 처리하는 경우 이메일 기능을 변경하면 결제 기능이 중단될 수 있습니다. 이러한 책임을 분리함으로써 한 부분의 변경이 다른 부분에 영향을 미칠 위험을 최소화할 수 있습니다.

예:

class EmailSender:
    def send_email(self, recipient, subject, body):
        # Code to send an email
        print(f"Sending email to {recipient} with subject '{subject}'")

class PaymentProcessor:
    def process_payment(self, amount):
        # Code to process payment
        print(f"Processing payment of amount {amount}")

# Usage
email_sender = EmailSender()
email_sender.send_email("user@example.com", "Hello!", "Welcome to our service!")

payment_processor = PaymentProcessor()
payment_processor.process_payment(100)

이 예에서 EmailSender는 이메일 전송만 담당하고 PaymentProcessor는 결제 처리만 담당합니다. 각각은 단일한 책임을 갖고 있으므로 코드를 더 쉽게 유지 관리하고 확장할 수 있습니다.

2. O - 개방형/폐쇄형 원칙(OCP)

정의: 소프트웨어 엔터티(예: 클래스, 모듈, 함수 등)는 확장을 위해 열려 있어야 하고 수정을 위해 닫혀 있어야 합니다.

설명: 이는 기존 코드를 변경하지 않고도 클래스에 새로운 기능이나 동작을 추가할 수 있어야 함을 의미합니다. 결제 처리 시스템이 있고 새 결제 방법을 추가하고 싶다고 가정해 보세요. 기존 코드를 수정하지 않고도 이 새로운 메소드를 추가할 수 있어야 합니다.

예:

from abc import ABC, abstractmethod

class PaymentProcessor(ABC):
    @abstractmethod
    def process_payment(self, amount):
        pass

class CreditCardPayment(PaymentProcessor):
    def process_payment(self, amount):
        print(f"Processing credit card payment of {amount}")

class PayPalPayment(PaymentProcessor):
    def process_payment(self, amount):
        print(f"Processing PayPal payment of {amount}")

# Usage
payments = [CreditCardPayment(), PayPalPayment()]
for payment in payments:
    payment.process_payment(100)

이 예에서 PaymentProcessor는 결제 처리 계약을 정의하는 추상 클래스입니다. CreditCardPayment 및 PayPalPayment는 이 클래스를 확장하는 구현입니다. 새로운 결제 수단을 추가하려면 기존 클래스를 수정하지 않고 PaymentProcessor를 확장하는 새 클래스를 생성하면 됩니다.

3. L - 리스코프 대체 원리(LSP)

정의: 하위 유형은 프로그램의 정확성을 변경하지 않고 기본 유형을 대체할 수 있어야 합니다.

설명: 이는 프로그램 기능에 영향을 주지 않고 슈퍼클래스의 객체를 서브클래스의 객체로 교체할 수 있어야 함을 의미합니다. 예를 들어 Vehicle 클래스와 함께 작동하는 함수가 있는 경우 Car 또는 Bike와 같은 모든 하위 클래스에서도 작동해야 합니다.

예:

class Vehicle:
    def start_engine(self):
        pass

class Car(Vehicle):
    def start_engine(self):
        print("Starting car engine...")

class Bike(Vehicle):
    def start_engine(self):
        print("Starting bike engine...")

# Usage
def start_vehicle_engine(vehicle: Vehicle):
    vehicle.start_engine()

car = Car()
bike = Bike()

start_vehicle_engine(car)  # Should work fine
start_vehicle_engine(bike) # Should work fine

이 예에서 Car와 Bike는 Vehicle의 하위 클래스입니다. start_vehicle_engine 함수는 Liskov 대체 원칙에 따라 하위 클래스의 세부 사항을 알 필요 없이 Vehicle의 모든 하위 클래스에서 작동할 수 있습니다.

4. I - 인터페이스 분리 원칙(ISP)

정의: 클라이언트는 자신이 사용하지 않는 인터페이스를 구현하도록 강요해서는 안 됩니다. 하나의 두꺼운 인터페이스 대신 각각 하나의 하위 모듈을 제공하는 메서드 그룹을 기반으로 하는 여러 개의 작은 인터페이스가 선호됩니다.

설명: 이 원칙은 하나의 범용 인터페이스가 아닌 클라이언트 유형별로 특정 인터페이스를 만들어야 함을 시사합니다. 인쇄하고, 스캔하고, 팩스를 보낼 수 있는 기계가 있다고 상상해 보세요. 인쇄 또는 스캔만 가능한 별도의 기계가 있는 경우 사용하지 않는 기능을 강제로 구현해서는 안 됩니다.

예:

from abc import ABC, abstractmethod

class Printer(ABC):
    @abstractmethod
    def print(self, document):
        pass

class Scanner(ABC):
    @abstractmethod
    def scan(self, document):
        pass

class MultiFunctionDevice(Printer, Scanner):
    def print(self, document):
        print(f"Printing: {document}")

    def scan(self, document):
        print(f"Scanning: {document}")

# Usage
mfd = MultiFunctionDevice()
mfd.print("Document 1")
mfd.scan("Document 2")

여기서 프린터와 스캐너는 별도의 인터페이스입니다. MultiFunctionDevice는 두 가지를 모두 구현하지만, 인쇄만 하거나 스캔만 하는 장치가 있는 경우 인터페이스 분리 원칙을 준수하여 사용하지 않는 메서드를 구현할 필요가 없습니다.

5. D - 종속성 역전 원칙(DIP)

정의: 상위 수준 모듈은 하위 수준 모듈에 종속되어서는 안 됩니다. 둘 다 추상화(예: 인터페이스)에 의존해야 합니다. 추상화는 세부사항에 의존해서는 안 됩니다. 세부 사항은 추상화에 따라 달라집니다.

설명: 상위 클래스가 하위 클래스에 직접 의존하는 대신 둘 다 인터페이스 또는 추상 클래스에 의존해야 합니다. 이를 통해 유연성이 향상되고 유지 관리가 쉬워집니다.

예:

from abc import ABC, abstractmethod

class NotificationService(ABC):
    @abstractmethod
    def send(self, message):
        pass

class EmailNotificationService(NotificationService):
    def send(self, message):
        print(f"Sending email: {message}")

class SMSNotificationService(NotificationService):
    def send(self, message):
        print(f"Sending SMS: {message}")

class NotificationSender:
    def __init__(self, service: NotificationService):
        self.service = service

    def notify(self, message):
        self.service.send(message)

# Usage
email_service = EmailNotificationService()
sms_service = SMSNotificationService()

notifier = NotificationSender(email_service)
notifier.notify("Hello via Email")

notifier = NotificationSender(sms_service)
notifier.notify("Hello via SMS")

이 예에서 NotificationSender는 EmailNotificationService 또는 SMSNotificationService와 같은 구체적인 클래스가 아닌 NotificationService 추상화에 의존합니다. 이 방법을 사용하면 NotificationSender 클래스를 변경하지 않고도 알림 서비스를 전환할 수 있습니다.

결론

• 단일 책임 원칙(SRP): 클래스는 한 가지 일을 잘 해야 합니다.

• 개방/폐쇄 원칙(OCP): 클래스는 확장을 위해 열려 있고 수정을 위해 닫혀 있어야 합니다.

• Liskov 대체 원칙(LSP): 하위 클래스는 기본 클래스를 대체할 수 있어야 합니다.

• 인터페이스 분리 원칙(ISP): 어떤 클라이언트도 자신이 사용하지 않는 방법에 의존하도록 강요받아서는 안 됩니다.

• 종속성 역전 원칙(DIP): 구체적인 구현이 아닌 추상화에 의존합니다.

이러한 SOLID 원칙을 따르면 이해, 유지 관리 및 확장이 더 쉬운 소프트웨어를 만들 수 있습니다.

위 내용은 SOLID 원칙 - Python의 실제 예제를 사용하여 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!