Deep Dive Into Design Patterns - 데코레이터 패턴

💡 데코레이터(Decorator) 패턴이란?대상 객체에 대한 기능 확장이나 변경이 필요할 때 객체의 결합(새로운 행동을 포함한 특수 래퍼 객체들 내에 추가)을 통해 서브클래싱 대신 쓸 수 있는 구조적 디자인 패턴입니다. 데코레이터 패턴을 이용하면 필요한 추가 기능의 조합을 런타임에서 동적으로 생성할 수 있습니다. 대상 객체를 새로운 행동들을 포함한 데코레이터 객체에 넣어서 행동들을 해당 장식자 객체마다 연결시킵니다. 서브클래스로 구성할 때 보다 훨씬 유연하게 기능을 확장 할 수 있고, 기능을 구현하는 클래스들을 분리함으로써 수정이 용이해집니다. 💡 클래스 다이어그램으로 본 데코레이터 패턴Component : 원본 객체와 장식된 객체 모두를 묶는 역할.Concrete Component : 원본 객체. ..

Deep Dive Into Design Patterns - 커맨드 패턴

💡 커맨드(Command) 패턴이란?요청(기능)을 캡슐화하여 요청에 대한 모든 정보를 객체화하는 행동 디자인 패턴입니다. 요청에 대한 정보로는 메서드 이름, 매개변수 등이 있으며, 사용자가 보낸 요청을 저장, 로깅, 또는 취소할 수 있습니다. 💡 클래스 다이어그램으로 본 커맨드 패턴발동자(Invoker) : 요청들을 시작하는 역할을 하는 클래스로, 수신자 대신 커맨드 객체를 작동시킴으로써 요청합니다. 또, 요청에 대한 기록을 남길 수 있고, 한 발동자 객체에 다수의 커맨드 객체가 전달될 수 있습니다.Command Interface : 일반적으로 커맨드를 실행하기 위한 단일 메서드만을 선언합니다.Concrete Command : 다양한 유형의 요청을 구현. 자체적으로 작업을 수행해서는 안 되며, 대신 ..

Deep Dive Into Design Patterns - 전략 패턴

💡 전략(Strategy) 패턴이란?알고리즘들의 패밀리를 정의하고, 각 패밀리를 별도의 클래스에 넣은 후 그들의 객체들을 상호교환할 수 있도록 하는 행동 디자인 패턴입니다. 실행(런타임) 중에 알고리즘 전략을 선택하여 객체 동작을 실시간으로 바뀌도록 할 수 있습니다. 즉, 어떤 일을 수행하는 알고리즘이 여러가지일 때, 동작들을 미리 전략으로 정의함으로써 손쉽게 전략을 교체할 수 있게 합니다. 따라서 알고리즘 변형이 빈번하게 필요한 경우에 적합합니다. GoF의 디자인 패턴 책에서는 전략 패턴을 다음과 같이 정의합니다.동일 계열의 알고리즘군을 정의하고각각의 알고리즘을 캡슐화하며,알고리즘을 사용하는 클라이언트와 상관없이 독립적으로알고리즘을 다양하게 변경할 수 있게 한다.즉, 전략 패턴은 SOLID 원칙의 O..

Deep Dive Into Design Patterns - 상태 패턴

💡 상태(State) 패턴이란?객체의 내부 상태가 변경될 때 해당 객체가 그의 행동을 변경할 수 있도록 하는 행동 디자인 패턴입니다. 객체가 행동을 변경할 때 객체가 클래스를 변경한 것처럼 보일 수 있습니다. 즉, 상태를 조건문으로 검사해서 행위를 달리하는 것이 아닌, 상태를 객체화 하여 상태가 행동을 할 수 있도록 위임하는 패턴을 말합니다. 전략 패턴(Strategy Pattern)이 '전략 알고리즘'을 클래스로 표현한 패턴이라면, 상태 패턴(State Pattern)은 '객체 상태'를 클래스로 표현한 패턴이라고 보면 됩니다. 따라서 상태 패턴의 클래스 다이어그램을 보면 전략 패턴과 매우 유사합니다. 그러나, 상태 패턴에서의 특정 상태들은 서로를 인식하고 한 상태에서 다른 상태로 전이를 시작할 수 있..

Deep Dive Into Design Patterns - 템플릿 메서드 패턴

💡 템플릿 메서드(Template Method) 패턴이란?부모 클래스에서 알고리즘의 골격을 정의하지만, 해당 알고리즘의 구조를 변경하지 않고 자식 클래스들이 알고리즘의 특정 단계들을 오버라이드(재정의)할 수 있도록 하는 행동 디자인 패턴입니다. 여러 클래스에서 공통으로 사용하는 메서드를 템플릿화 하여 상위 클래스에서 정의하고, 하위 클래스마다 세부 동작 사항을 다르게 구현합니다. 템플릿 메소드 패턴은 상속이라는 기술을 극대화하여,알고리즘의 뼈대를 맞추는 것에 초점을 둡니다. 이미 수많은 프레임워크에서 많은 부분에 템플릿 메소드 패턴 코드가 우리도 모르게 적용되어 있습니다. 💡 클래스 다이어그램으로 본 템플릿 메서드 패턴Abstract Class : 알고리즘의 단계들의 역할을 하는 메서드들을 선언하며,..

Deep Dive Into Design Patterns - 빌더 패턴

💡 빌더(Builder) 패턴이란?객체를 생성하기 전에 점진적으로 객체의 정보를 수집하여 복잡한 객체들을 단계 별로 생성하는 생성 디자인 패턴입니다. 생성자에 들어갈 매개 변수를 메서드로 하나하나 받아들이고 마지막에 통합 빌드해서 객체를 생성하는 방식입니다. 일반적으로는 생성자를 제공하여 객체를 생성하지만, 생성 객체에 초기값을 주거나 생성할 클래스를 선택하고 싶을 때 변형이 필요합니다. 즉, 객체 생성을 클래스 로직 밖으로 옮길 필요가 있을 때 빌더 패턴을 사용합니다.public static void main(String[] args) { // 생성자 방식 Hamburger hamburger = new Hamburger(2, 3, 0, 3, 0, 0); // 빌더 방식 Hambu..

Deep Dive Into Design Patterns - 플라이웨이트 패턴

💡 플라이웨이트(Flyweight) 패턴이란?재사용 가능한 객체 인스턴스를 공유시켜 메모리 사용량을 최소화하는 구조 패턴입니다. 각 객체에 모든 데이터를 유지하는 대신 여러 객체들 간에 상태의 공통 부분들을 공유하여 사용할 수 있는 RAM에 더 많은 객체들을 포함할 수 있도록 합니다. 자주 변하는 속성(extrinsic)과 변하지 않는 속성(intrinsic)을 분리하고, 변하지 않는 속성을 캐시하여 재사용해 메모리 사용을 줄입니다. 그래서 동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하여 사용하도록 하여 최적화를 노리는 경량 패턴이라고 불립니다. 💡 클래스 다이어그램으로 본 플라이웨이트 패턴Flyweight : 경량 객체를 묶는 인터페이스.Flyweight State : 플라이웨이..

Deep Dive Into Design Patterns - 책임 연쇄 패턴

💡 책임 연쇄(Chain of Responsibility) 패턴이란?핸들러들의 체인(사슬)을 따라 요청을 전달할 수 있게 해주는 행동 디자인 패턴입니다. 클라이어트의 요청에 대한 세세한 처리를 하나의 객체가 몽땅 하는 것이 아닌, 여러 개의 처리 객체들로 나누고, 이들을 사슬(chain)처럼 연결해 집합 안에서 연쇄적으로 처리하는 행동 패턴입니다. 이러한 처리 객체들을 핸들러(handler)라고 부르는데, 요청을 받으면 각 핸들러는 요청을 처리할 수 있는지 판단하고, 없으면 체인의 다음 핸들러로 처리에 대한 책임을 전가합니다. 처리에 대한 책임을 요청을 보내는 쪽(sender)과 요청을 처리하는(receiver) 쪽을 분리하여 각 객체를 부품으로 독립시키고 결합도를 느슨하게 만들며, 상황에 따라서 요청..

Deep Dive Into Design Patterns - 프록시 패턴

💡 프록시 패턴이란?대상 원본 객체를 대리하여 대신 처리하게 함으로써 로직의 흐름을 제어하는 행동 패턴입니다. “프록시”의 사전적인 의미인 ‘대리인’처럼, 클라이언트가 대상 객체를 직접 사용하는 게 아니라 중간에 프록시(대리인)을 거쳐서 사용하는 코드 패턴입니다. 따라서 대상 객체(Subject)의 메소드를 직접 실행하는 것이 아닌, 대상 객체에 접근하기 전에 프록시(Proxy) 객체의 메서드를 접근한 후 추가적인 로직을 처리한뒤 접근하게 됩니다. 프록시는 실제 객체에 액세스하지 않고, 정상적 또는 비정상적인 메시지를 처리할 수 있게끔 합니다. 💡 프록시 패턴을 쓰는 이유프록시 패턴은 대상 클래스가 민감한 정보를 가지고 있거나 인스턴스화 하기에 무겁거나 추가 기능을 가미하고 싶은데, 원본 객체를 수정..

Deep Dive Into Design Patterns - 중재자 패턴

💡 중재자(Mediator) 패턴이란? 객체 간의 혼란스러운 의존 관계들을 줄일 수 있는 행동 디자인 패턴입니다. 이 패턴은 객체 간의 직접 통신을 제한하고 중재자 객체를 통해서만 협력하도록 합니다. 중재자 패턴은 각 객체들의 강한 연결(참조)를 끊고, 그 대신 컴포넌트들이 특수 중재자 객체를 호출하여 적절한 컴포넌트들로 리다이렉션하게끔 합니다. 이로 인해 컴포넌트들은 간접적으로 협력하게 되고, 수십 개의 동료 컴포넌트들과 결합되는 대신 단일 중재자 클래스에만 의존합니다. ⭐ 옵서버 패턴과 중재자 패턴? 옵서버 패턴은 1개의 발행자에 N개의 구독자가 존재하여 옵서버가 발행을 담당하고 중재자 패턴은 M개의 퍼블리셔와 N개의 구독자 사이에서 1개의 중재자를 통해 통신합니다. 옵서버 패턴은 재사용성은 좋지만 ..

Deep Dive Into Design Patterns - 옵서버 패턴

💡 옵서버(Observer) 패턴이란? 객체에 발생하는 모든 이벤트에 대하여 옵서버(관찰자)들에게 알리고, 옵서버들은 알림을 받아 조치를 취하는 행동 패턴입니다. 일명 구독 매커니즘을 구현한 패턴으로, 다른 디자인 패턴들과 다르게 일대다 의존성을 가집니다. 옵서버 패턴의 예시로는 MVC 패턴(Model, View, Controller)이 있습니다. MVC의 Model과 View의 관계는 Observer 패턴의 Subject 역할과 Observer 역할의 관계에 대응됩니다. 즉, 하나의 Model에 복수의 View가 대응합니다. 💡 클래스 다이어그램으로 본 옵서버 패턴 Publisher(Subject) : 관찰 당하는 대상으로, Subscriber(Observer)들을 리스트로 갖고 있다. (Aggrega..

Deep Dive Into Design Patterns - 싱글톤 패턴

💡 싱글톤(Singleton) 패턴이란? 클래스에 인스턴스가 하나만 있도록 하면서 이 인스턴스에 대한 전역 접근(액세스) 지점을 제공하는 생성 디자인 패턴입니다. 쉽게 말해, 단 하나의 유일한 객체를 만들기 위한 코드 패턴이며 인스턴스가 필요할 때 똑같은 인스턴스를 새로 만들지 않고 기존의 인스턴스를 가져와 활용하는 기법을 말합니다. 보통 싱글톤 패턴이 적용된 객체가 필요한 경우는 그 객체가 리소스를 많이 차지하는 역할을 하는 무거운 클래스일때 적합합니다. 대표적으로 데이터베이스 연결 모듈을 예로 들 수 있는데, 데이터베이스에 접속하는 작업(I/O 바운드)은 그 자체로 무거운 작업에 속하며 또한 한번만 객체를 생성하고 돌려쓰면 되지 굳이 여러번 생성할 필요가 없기 때문입니다. 💡 클래스 다이어그램으로 본..