디자인 패턴

* 헤드퍼스트 디자인패턴(개정판), Node.js 디자인 패턴 바이블 책을 보며 이해하고 작성, 참고 또는 직접 작성한 코드를 적어본다.

* 구상(Concrete) 클래스: new 키워드를 사용하여 인스턴스를 만드는 클래스(=구현 클래스)

* 추상(Abstract) 클래스: 하나의 추상 메소드를 포함하는 클래스로 이를 상속하는 자식 클래스는 추상 메소드를 구현해야함

* 인터페이스(Interface): 클래스의 공통된 기능을 정리한 명세서

* 컨택스트(Context): 사용자가 관심 있는 인터페이스를 정의/문제에 대한 정의,상황

 

옵저버

 

 

 

전략 패턴

• 특정 변경이 필요한 부분을 별도의 상호 교환 가능한 (전략) 객체로 추출하여 로직의 변경이 용이하도록 함
• 추출하여 합성하는 것이 포인트
• 해당 패턴을 알기전에 합성하는 부분에 대해서는 경험이 있었으나 요구상황에 따라 다르게 합성하는 것에 대한 경험은 없었고 사실 fly/flyable과 같이 나눈다는 것에 대한 개념은 그전엔 생각해보지 않았던 것 같음

from abc import *


class AbstractAnimal(metaclass=ABCMeta):
    name = "name"
    weight = 0
    height = 0

    @abstractmethod
    def description(self):
        print('description')

class Flyable():
    def fly(self):
        print("fly")


class NonFlyable():
    def fly(self):
        print("can't fly")
    

class Runable():
    def run(self):
        print("run")


class NonRunable():
    def run(self):
        print("can't run")

class Dog(AbstractAnimal, Runable, NonFlyable):

    def __init__(self, name, weight, height):
        self.name = name
        self.weight = weight
        self.height = height
    

    def description(self):
        print(f"dog description, name: {self.name}, weight: {self.weight}, height: {self.height}")



Albi = Dog("Albi", 22, 100)
Albi.description()
Albi.run()
Albi.fly()


class Bird(AbstractAnimal, NonRunable, Flyable):

    def __init__(self, name, weight, height):
        self.name = name
        self.weight = weight
        self.height = height
    

    def description(self):
        print(f"bird description, name: {self.name}, weight: {self.weight}, height: {self.height}")

    


Sevi = Bird("Sevi", 16, 60)
Sevi.description()
Sevi.run()
Sevi.fly()

 

 

상태 패턴

• 전략 패턴과 유사할수 있으나 대상 컴포넌트(=컨택스트)의 상태를 추출한 클래스에서 각 상태에 대응되는 작업을 수행함
• 컨택스트 메서드 내의 상태에 따른 조건문 코드를 없애고 상태 클래스로 모든 작업을 위임함
• 내부 상태가 변경할때 행동이 달라지게 되고 컨택스트는 그대로이나 바뀐 것 같은 결과를 얻음

from __future__ import annotations
from abc import ABC, abstractmethod
from time import time


class FailsafeSocket:
    def __init__(self) -> None:
        self.queue = []
        self.states = {
            "offline": Offline(self),
            "online": Online(self),
            "pending": Pending(self),
        }
        self.change_state("offline")

    def change_state(self, state):
        self.state = self.states[state]

    def send(self, data):
        self.state.send(data)


class AbstractState(ABC):
    @abstractmethod
    def send(self) -> None:
        pass


class Offline(AbstractState):
    def __init__(self, FailsafeSocket):
        self.socket = FailsafeSocket

    def send(self, data) -> None:
        print(f"{type(self).__name__} {data} not sent ")


class Pending(AbstractState):
    def __init__(self, FailsafeSocket):
        self.socket = FailsafeSocket

    def send(self, data) -> None:
        self.socket.queue.append(data)
        print(f"{type(self).__name__} data {data} added to queue: {self.socket.queue}")


class Online(AbstractState):
    def __init__(self, FailsafeSocket):
        self.socket = FailsafeSocket

    def send(self, data) -> None:
        if len(data) > 5:
            self.socket.change_state("offline")
            print(f"{type(self).__name__} too long data {data}, change to noline")
            self.socket.queue = []
        else:
            self.socket.queue.append(data)
            print(f"{type(self).__name__} sent data: {self.socket.queue}")
            self.socket.queue = []


# 상태가 ON/OFF 일때 context의 send에서 분기가 있는 것이 아니라 해당 상태 객체에 정의된 메서드에 의해 할일을 수행
# 상태가 여러개라고 가저한다면 if 선언문을 제거할수 있고
# 상태의 변경에는 닫혀있지만 상태 확장에는 열려있음


if __name__ == "__main__":
    socket = FailsafeSocket()
    socket.send("1")
    socket.send("2")
    socket.send("3")
    socket.change_state("pending")
    socket.send("4")
    socket.send("5")
    socket.send("6")
    socket.change_state("online")
    socket.send("7")
    socket.send("8")
    socket.send("9")
    socket.send("11111111")
    socket.send("1")

    # socket1 = FailsafeSocket()
    # socket1.send("1")
    # socket1.send("2")
    # socket1.send("3")
    # socket1.change_state("pending")
    # socket1.send("4")
    # socket1.send("5")
    # socket1.send("6")
    # socket1.change_state("online")
    # socket1.send("7")
    # socket1.send("8")
    # socket1.send("9")

    # print(socket1 == socket)  # false
    # print(socket.state.socket == socket1.state.socket)  # false

•  전략과 상태 패턴
  • 전략 패턴은 어떤 전략 객체를 사용할지 클라이언트가 지정해주지만(=>처음 실행 시 객체 변경의 유연성)
  • 상태 패턴은 행동을 상태 객체 내에 캡슐화하여 Context 내의 상태 객체를 바꾸는 것만으로 객체의 행동을 바꾼다.

 

템플릿 메서드 패턴

• 부모 클래스에서 추상 메서드를 포함한 일부 메서드들을 구현하고, 자식 클래스에서 요구사항에 따라 다른 메서드들(추상 메서드, 메서드 오버라이드(옵션))을 구현하여 특정 단계들만 확장하기 위함
• 상속을 기반을 함
• 클래스를 만들때 템플릿 메서드 패턴인지 모르고 이 패턴을 사용한 경험이 많이 있음

• 전략과 템플릿 메서드패턴
  • 전략은 구상클래스들을 합성, 템플릿 메서드는 자식 클래스들을 확장하는 것에 초점
  • 전략 패턴은은 객체 수준에서 작동하므로 런타임에 행동들을 전환, 템플릿 메서드는 클래스 수준에서 작동하므로 정적

 

 

싱글턴 패턴

• Python의 Flask 에서 app 이라는 객체를 바로 실행하는 것이 아니라 create_app()이라는 함수를 호출하여 app을 받도록 하는 부분에서 많이 사용했었고, DB Connection에 적용했던 경험이 있음

 

팩토리 패턴

 

빌더 패턴

• 객체 생성을 단순화하는 생성 디자인 패턴 -> 단계별 객체 생성하거나 복잡한 객체를 만들때 가독성 및 사용성이 향상됨
• 장점을 최대화할수 있는 경우는 인자가 목록이 길거나 복잡한 매개변수 입력을 사용하는 생성자가 있는 클래스
• 예를 들어 입력되던 파라미터가 변경이 필요할때 손쉽게 해결할 수 있음
• 파라미터 입력값이 많아질수록 복잡하고 순서를 외우야함
• 파이썬의 경우 키워드 파라미터가 존재해서 빌더 패턴의 장점이 큰 장점이 아니다. 바로 키워드를 지정해서 진행할 수 있고 이경우 순서또한 상관 없음

class UrlBuilder {

    setProtocol(protocol) {
        this.protocol = protocol
        return this
    }

    setHost(host) {
        this.host = host
        return this
    }

    setPort(port) {
        this.port = port
        return this
    }

    build() {
        return `${this.protocol}://${this.host}:${this.port}`
    }
}

const url = new UrlBuilder()
    .setProtocol('http')
    .setHost('localhost')
    .setPort('3000')
    .build() 

console.log(url) // http://localhost:3000

 

커맨드 패턴

 

데코레이터 패턴

 

 

 

어댑터 패턴

• 특정 클래스 인터페이스를 클라이언트에서 요구하는 다른 인터페이스로 변환: 인터페이스가 호환되지 않아 사용할 수 없는 클래스를 사용할 수 있게 해준다.
•  

 

퍼사드패턴

• 인터페이스를 단순하게 만들고 클라이언트와 구성 요소로 이루어진 서브시스템으로 분리함
• NestJS에서 Controller에서 여러 서비스 레이어들을 의존할때 이 수가 많아진다면 이를 분리하여 하나의 퍼사드레이어를 의존하고 퍼사드 레이어에서 기존 서비스들을 의존하게 하여 분리/단순하게 함

export class AggregationFacade {
  constructor(
    private readonly _userService: UserService,
    private readonly _orderService: OrderService,
    private readonly _paymentService: PaymentService,
  ) {}
}

어댑터 패턴과 퍼사드 패턴

• 둘다 여러 개의 클래스를 감쌀 수 있지만, 퍼사드는 인터페이스를 단순하게 만드는 용도이고 어댑터는 인터페이스를 다른 인터페이스를 변환함

 

 

....