GoF 디자인 패턴

😃 디자인 패턴

 

디자인 패턴은 객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 해결하기 위해 사용되는 패턴입니다.

 

 

📗 생성 패턴

기존 코드의 유연성과 재사용을 증가시키는 객체를 생성하는 다양한 방법을 제공합니다.

 

팩토리 메서드(Factory Method)	객체 생성 처리를 서브 클래스로 분리해 처리하도록 캡슐화하는 패턴
추상 팩토리(Abstract Factory)	구체적인 클래스에 의존하지 않고 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴
빌더(Builder)	복잡한 객체들을 단계별로 생성할 수 있도록 하는 패턴
프로토타입(Prototype)	클래스들에 의존시키지 않고 기존 객체들을 복사할 수 있도록 하는 패턴
싱글톤(Singleton)	클래스의 인스턴스가 하나만 존재하도록 보장하는 패턴

 

 

 

📕 팩토리 메서드 패턴 ( Factory Method Pattern )

팩토리 메소드 패턴은 객체 생성을 공장(Factory) 클래스로 캡슐화 처리하여 대신 생성하게 하는 생성 디자인 패턴이다.

즉, 클라이언트에서 직접  new  연산자를 통해 제품 객체를 생성하는 것이 아닌, 제품 객체들을 도맡아 생성하는 공장 클래스를 만들고, 이를 상속하는 서브 공장 클래스의 메서드에서 여러가지 제품 객체 생성을 각각 책임 지는 것이다.

또한 객체 생성에 필요한 과정을 템플릿 처럼 미리 구성해놓고, 객체 생성에 관한 전처리나 후처리를 통해 생성 과정을 다양하게 처리하여 객체를 유연하게 정할 수 있는 특징도 있다.

 

정리하자면, 팩토리 메소드 패턴은 객체를 만들어내는 공장(Factory 객체)을 만드는 패턴이라고 보면 된다. 그리고 어떤 클래스의 인스턴스를 만들지는 미리 정의한 공장 서브 클래스에서 결정한다.

겨우 객체 생성 가지고 이런식으로 번거롭게(?) 구성하는 이유는 객체간의 결합도가 낮아지고 유지보수에 용이해지기 때문이다.

 

 

 

 

📕 추상 팩토리 패턴( Abstract Factory Pattern )

추상 팩토리 패턴은 연관성이 있는 객체 군이 여러개 있을 경우 이들을 묶어 추상화하고, 어떤 구체적인 상황이 주어지면 팩토리 객체에서 집합으로 묶은 객체 군을 구현화 하는 생성 패턴이다. 클라이언트에서 특정 객체을 사용할때 팩토리 클래스만을 참조하여 특정 객체에 대한 구현부를 감추어 역할과 구현을 분리시킬 수 있다.

즉, 추상 팩토리의 핵심은 제품 '군' 집합을 타입 별로 찍어낼수 있다는 점이 포인트 이다. 예를들어 모니터, 마우스, 키보드를 묶은 전자 제품군이 있는데 이들을 또 삼성 제품군이냐 애플 제품군이냐 로지텍 제품군이냐에 따라 집합이 브랜드 명으로 여러갈래로 나뉘게 될때, 복잡하게 묶이는 이러한 제품군들을 관리와 확장하기 용이하게 패턴화 한것이 추상 팩토리 이다.

 

 

 

 

📕 빌더 ( Builder )

빌더 패턴(Builder Pattern)은 복잡한 객체의 생성 과정과 표현 방법을 분리하여 다양한 구성의 인스턴스를 만드는 생성 패턴이다. 생성자에 들어갈 매개 변수를 메서드로 하나하나 받아들이고 마지막에 통합 빌드해서 객체를 생성하는 방식이다. 

이해하기 쉬운 사례로 수제 햄버거를 들 수 있다. 수제 햄버거를 주문할때 빵이나 패티 등 속재료들은 주문하는 사람이 마음대로 결정된다. 어느 사람은 치즈를 빼달라고 할수 있고 어느 사람은 토마토를 빼달라고 할수 있다. 이처럼 선택적 속재료들을 보다 유연하게 받아 다양한 타입의 인스턴스를 생성할수 있어, 클래스의 선택적 매개변수가 많은 상황에서 유용하게 사용된다.

 

 

 

 

📕 프로토타입( Prototype )

자바스크립트는 프로토타입 기반 언어라고 불립니다.

자바스크립트 개발을 하면 빠질 수 없는 것이 프로토타입인데요.

프로토타입이 거의 자바스크립트 그 자체이기때문에 이해하는 것이 어렵고 개념도 복잡합니다.

​

자바스크립트에 클래스는 없지만 함수(function)와 new를 통해 클래스를 비스무리하게 흉내낼 수 있습니다.

 

 

 

 

📕 싱글톤( Singleton )

싱글톤 패턴이란 단 하나의 유일한 객체를 만들기 위한 코드 패턴이다.

쉽게 말하자면 메모리 절약을 위해, 인스턴스가 필요할 때 똑같은 인스턴스를 새로 만들지 않고 기존의 인스턴스를 가져와 활용하는 기법을 말한다.

우리가 전역 변수라는 걸 만들어 이용하는 이유는, 똑같은 데이터를 메서드마다 지역 변수로 선언해서 사용하면 무의미하기도 않고 낭비이기 때문에, 전역에서 한번만 데이터를 선언하고 가져와 사용하면 효율적이기 때문이다.

이러한 개념을 그대로 클래스에 대입한 것이 싱글톤 패턴이라고 이해하면 된다.

따라서 보통 싱글톤 패턴이 적용된 객체가 필요한 경우는 그 객체가 리소스를 많이 차지하는 역할을 하는 무거운 클래스일때 적합하다.

 

대표적으로 데이터베이스 연결 모듈을 예로 들 수 있는데, 데이터베이스에 접속하는 작업(I/O 바운드)은 그 자체로 무거운 작업에 속하며 또한 한번만 객체를 생성하고 돌려쓰면 되지 굳이 여러번 생성할 필요가 없기 때문이다.

이밖에도 디스크 연결, 네트워크 통신, DBCP 커넥션풀, 스레드풀, 캐시, 로그 기록 객체 등에 이용된다.

이러한 객체들은 또 새로 만들어서 사용될 일도 없거니와 사용해도 리소스 낭비일 뿐이다. 따라서 어플리케이션에서 유일해야 하며 유일한 것이 좋은 것을 싱글톤 객체로 만들면 된다고 보면 된다.

 

 

 

 

 

📗 구조 패턴

구조를 유연하고 효율적으로 유지하면서 객체와 클래스를 더 큰 구조로 조합하는 방법을 설명합니다.

 

어댑터(Adapter)	호환되지 않는 인터페이스를 가진 객체들이 협업할 수 있도록 하는 패턴
브릿지(Bridge)	클래스 또는 밀접하게 관련된 클래스들의 집합을 두 개의 개별 계층구조(추상화 및 구현)로 나눈 후 각각 독립적으로 개발할 수 있도록 하는 패턴
복합체(Composite)	객체들을 트리 구조로 구성한 후, 복합객체와 단일객체를 구분 없이 다루는 패턴
데코레이터(Decorator)	객체들을 새로운 행동들을 포함한 특수 래퍼 객체들 내에 넣어서 위 행동들을 해당 객체들에 연결시키는 패턴
파사드(Facade)	서브 시스템 집합에 대해 하나의 통합된 인터페이스를 제공하는 패턴
플라이웨이트(Flyweight)	각 객체에 데이터를 유지하는 대신 여러 객체들의 상태의 공통 부분을 공유하여 RAM에 더 많은 객체를 포함하게 하는 패턴
프록시(Proxy)	원본 객체를 대신하여 처리하게 함으로써 흐름을 제어하는 패턴

 

 

 

 

📕 어댑터 패턴( Adaptor Pattern )

어댑터 패턴(Adaptor Pattern) 이란 이름 그대로 클래스를 어댑터로서 사용되는 구조 패턴이다.

어댑터는 우리 주변에도 많이 볼 수 있는 것으로서, 대표적으로 110V 전용 가전제품에 220V 어댑터를 끼워 사용하는 걸 들 수 있다. 즉, 서로 호환이 되지 않은 단자를 어댑터로 호환시켜 작동시키게끔 하는 것이 어댑터의 역할인 것이다. 

 

 

 

📕 브릿지 패턴( Bridge Pattern )

브릿지 패턴은 객체의 확장성을 향상하기 위한 패턴으로, 객체에서 동작을 처리하는 구현부와 확장을 위한 추상부를 분리한다.

• 브리지 패턴은 기능을 처리하는 클래스와 구현을 담당하는 추상 클래스로 구별한다. 구현뿐 아니라 추상화도 독립적 변경이 필요할 때 브리지 패턴을 사용한다.
• 2개의 객체는 추상화를 구현에서 분리하여 매우 독립적으로 사용할 수 있어야 한다.
• 브리지 패턴은 기존 시스템에 부수적인 새로운 기능들을 지속적으로 추가할 때 사용하면 유용하다.
• 브리지 패턴은 새로운 인터페이스를 정의하여 기존 프로그램의 변경 없이 기능을 확장할 수 있다.

 

 

 

📕 복합체 패턴( Composite Pattern )

복합체 패턴(Composite Pattern)은 복합 객체(Composite) 와 단일 객체(Leaf)를 동일한 컴포넌트로 취급하여, 클라이언트에게 이 둘을 구분하지 않고 동일한 인터페이스를 사용하도록 하는 구조 패턴이다.

복합체 패턴은 전체-부분의 관계를 갖는 객체들 사이의 관계를 트리 계층 구조로 정의해야 할때 유용하다. 윈도우나 리눅스의 파일 시스템 구조를 떠올려보면 쉽게 이해할 수 있다.

폴더(디렉토리) 안에는 파일이 들어 있을수도 있고 파일을 담은 또 다른 폴더도 들어있을 수 있다. 이를 복합적으로 담을수 있다 해서 Composite 객체라고 불리운다. 반면 파일은 단일 객체 이기 때문에 이를 Leaf 객체라고 불리운다. 즉 Leaf는 자식이 없다. 복합체 패턴은 바로 이 폴더와 파일을 동일한 타입으로 취급하여 구현을 단순화 시키는 것이 목적이다. 폴더 안에는 파일 뿐만 아니라 서브 폴더가 올 수 있고 또 서브 폴더 안에 서브 폴더가 오거나 하는 계층 구조를 구현하다 보면, 자칫 복잡해 질 수 도 있는 복합 객체를 재귀 동작을 통해 하위 객체들에게 작업을 위임한다. 그러면 복합 객체와 단일 객체를 대상으로 똑같은 작업을 적용할 수 있어 단일 / 복합 객체를 구분할 필요가 거의 없어진다. 

윈도우에선 폴더와 파일은 엄연히 다른 놈이지만, 리눅스(Unix)에선 디렉토리와 파일은 모두 파일로 취급된다. 어찌보면 리눅스 OS가 복합체(Composite) 패턴을 통해 계층 구조를 구현하였다고 볼 수 있다. 당연히 실제 설계는 다르겠지만, 복합체 패턴은 입문하기 어려운 패턴중 하나이기에 이러한 비유를 통해 좀더 패턴에 친숙하게 접근하도록 해보자.

 

정리하자면, Composite 패턴은 그릇과 내용물을 동일시해서 재귀적인 구조를 만들기 위한 디자인 패턴이라고 말할 수 있다.

 

 

 

📕 데코레이터 패턴( Decorator Pattern )

데코레이터 패턴(Decorator Pattern)은 대상 객체에 대한 기능 확장이나 변경이 필요할때 객체의 결합을 통해 서브클래싱 대신 쓸수 있는 유연한 대안 구조 패턴이다.

Decorator을 해석하자면 '장식자' 라는 의미를 가지고 있는데,  마치 기본 제품에 포장지나 외부 디자인을 살짝 변경해 줌으로써 새로운 기능을 부여하는 것과 같이, 객체 지향 프로그래밍에서 원본 객체에 대해서 무언가를 장식하여 더 멋진 기능을 가지게 만드는 것이기 때문에 이 명칭이 붙었다고 보면 된다.

데코레이터 패턴을 이용하면 필요한 추가 기능의 조합을 런타임에서 동적으로 생성할 수 있다. 데코레이터할 대상 객체를 새로운 행동들을 포함한 특수 장식자 객체에 넣어서 행동들을 해당 장식자 객체마다 연결시켜, 서브클래스로 구성할때 보다 훨씬 유연하게 기능을 확장 할 수 있다. 그리고 기능을 구현하는 클래스들을 분리함으로써 수정이 용이해진다.

 

 

 

📕 파사드 패턴 ( Facade Pattern )

먼저 파사드(Facade)는 프랑스어 Façade 에서 유래된 단어로 건물의 '외관'이라는 뜻입니다.
하위 시스템(내부 구조)에 있는 인터페이스들에 대한 통합된 고급 인터페이스(외벽)를 제공하는 패턴입니다.
이로써 내부 시스템의 복잡도를 감추기 위해 복잡한 기능을 감싸고 상호 작용할 더 단순한 메소드를 제공하는 계층을 생성하고 서브시스템과 상호 작용 복잡도를 낮추는데 의미가 있습니다.

• 클라이언트의 요청을 서브시스템 객체에 전달하는 단순하고 일관된 통합 인터페이스입니다.
• 클라이언트와 서브시스템이 긴밀하게 연결되는 것을 방지하며 서브시스템과의 상호 작용의 복잡도를 낮춥니다.

 

 

📕 플라이웨이트 패턴( Flyweight Pattern )

플라이웨이트 패턴(Flyweight Pattern)은 재사용 가능한 객체 인스턴스를 공유시켜 메모리 사용량을 최소화하는 구조 패턴이다. 간단히 말하면 캐시(Cache) 개념을 코드로 패턴화 한것으로 보면 되는데, 자주 변화는 속성(extrinsit)과 변하지 않는 속성(intrinsit)을 분리하고 변하지 않는 속성을 캐시하여 재사용해 메모리 사용을 줄이는 방식이다. 그래서 동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하여 사용하도록 하여 최적화를 노리는 경량 패턴이라고도 불린다.

Flyweight 단어 의미는 Fly(가벼운) + Weight(무게)를 뜻함으로써, 복싱의 체급에서 유래되었다. 이를 자바 프로그래밍에 접목해보면 모든 객체를 일일히 인스턴스화 하지않고 재사용할수 있는 객체는 재사용함으로써 메모리를 가볍게 만든다는 의미로서 쓰인다보 보면 된다.

 

 

 

📕 프록시 패턴( Proxy Pattern )

프록시 패턴(Proxy Pattern)은 대상 원본 객체를 대리하여 대신 처리하게 함으로써 로직의 흐름을 제어하는 행동 패턴이다.

프록시(Proxy)의 사전적인 의미는 '대리인'이라는 뜻이다. 즉, 누군가에게 어떤 일을 대신 시키는 것을 의미하는데, 이를 객체 지향 프로그래밍에 접목해보면 클라이언트가 대상 객체를 직접 쓰는게 아니라 중간에 프록시(대리인)을 거쳐서 쓰는 코드 패턴이라고 보면 된다. 따라서 대상 객체(Subject)의 메소드를 직접 실행하는 것이 아닌, 대상 객체에 접근하기 전에 프록시(Proxy) 객체의 메서드를 접근한 후 추가적인 로직을 처리한뒤 접근하게 된다.

 

 

 

 

 

 

📗 행동 패턴

객체 간의 효과적인 의사소통과 책임 할당을 처리합니다.

 

책임 연쇄(Chain of Responsibility)	요청을 받는 객체를 연쇄적으로 묶어 요청을 처리하는 객체를 만날 때까지 객체 Chain을 따라 요청을 전달함
커맨드(Command)	요청을 객체의 형태로 캡슐화하여 재사용하거나 취소할 수 있도록 저장함
인터프리터(Interpreter)	특정 언어의 문법 표현을 정의함
반복자(Iterator)	내부를 노출하지 않고 접근이 잦은 어떤 객체의 원소를 순차적으로 접근할 수 있는 동일한 인터페이스 제공
중재자(Mediator)	한 집합에 속해있는 객체들의 상호작용을 캡슐화하여 새로운 객체로 정의
메멘토(Memento)	객체가 특정 상태로 다시 되돌아올 수 있도록 내부 상태를 실체화
옵서버(Observer)	객체 상태가 변할 때 관련 객체들이 그 변화를 통지받고 자동으로 갱신될 수 있게 함
상태(State)	객체의 상태에 따라 동일한 동작을 다르게 처리해야할 때 사용
전략(Strategy)	동일 계열의 알고리즘군을 정의하고 캡슐화하여 상호교환이 가능하도록 함
템플릿 메소드(Template Method)	상위클래스는 알고리즘의 골격만을 작성하고 구체적인 처리는 서브클래스로 위임함
방문자(Visitor)	객체의 원소에 대해 수행할 연산을 분리하여 별도의 클래스로 구성함

 

 

 

 

📕 책임 연쇄 패턴( Chain Of Responsibility Pattern, COR )

책임 연쇄 패턴(Chain Of Responsibility Pattern, COR)은 클라이어트의 요청에 대한 세세한 처리를 하나의 객체가 몽땅 하는 것이 아닌, 여러개의 처리 객체들로 나누고, 이들을 사슬(chain) 처럼 연결해 집합 안에서 연쇄적으로 처리하는 행동 패턴이다.

이러한 처리 객체들을 핸들러(handler)라고 부르는데, 요청을 받으면 각 핸들러는 요청을 처리할 수 있는지, 없으면 체인의 다음 핸들러로 처리에 대한 책임을 전가한다. 한마디로 책임 연쇄라는 말은 요청에 대한 책임을 다른 객체에 떠넘긴다는 소리이다. 떠넘긴다고 하니까 부정적인 의미로 들릴수도 있겠지만, 이러한 체인 구성은 하나의 객체에 처리에 대한 책임을 요청을 보내는 쪽(sender)과 요청을 처리하는(receiver) 쪽을 분리하여 각 객체를 부품으로 독립시키고 결합도를 느슨하게 만들며, 상황에 따라서 요청을 처리할 객체가 변하는 프로그램에도 유연하게 대응할 수 있다는 장점을 가지고 있다. 특히나 중첩 if-else문들을 최적화하는데 있어 실무에서도 많이 애용되는 패턴중 하나이기도 하다.

 

 

 

 

 

📕 커맨드패턴( Command Pattern )

Command Pattern은 행동(behavioral) 디자인 패턴 중 하나로, 요청 자체를 객체화 하는 것을 목표로 합니다. 이 패턴은 요청이 서로 다른 사용자, 시간 또는 프로젝트에 따라 달라질 수 있을 때 유용합니다. 이러한 요청을 객체로 만들면, 요청을 큐에 저장하거나 로그로 기록하고 재실행할 수 있습니다.

 

 

 

 

 

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EB%B9%8C%EB%8D%94Builder-%ED%8C%A8%ED%84%B4-%EB%81%9D%ED%8C%90%EC%99%95-%EC%A0%95%EB%A6%AC

💠 빌더(Builder) 패턴 - 완벽 마스터하기

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EC%8B%B1%EA%B8%80%ED%86%A4Singleton-%ED%8C%A8%ED%84%B4-%EA%BC%BC%EA%BC%BC%ED%95%98%EA%B2%8C-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

💠 싱글톤(Singleton) 패턴 - 꼼꼼하게 알아보자

 

https://4z7l.github.io/2020/12/25/design_pattern_GoF.html