Programming/Design patterns

[Design patterns] Proxy Pattern (프록시 패턴)

Introduction 구조 시스템 패턴 시리즈의 완결까지 본 글을 포함해 두 편 남았다! 이번에 소개할 디자인 패턴은 Proxy 패턴이다. Proxy 패턴을 한줄 요약하면 다음과 같다. 어떤 오브젝트로의 접근을 중간에서 제어하기 위한 대리자 (proxy) 오브젝트를 제공한다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 살짝씩 내용을 변경한 부분이 있다. Motivation 어떤 오브젝트의 생성 코스트가 너무 커서, 전체 시스템을 처음 구성할 때에 바로 생성하지 않고 그것이 실제로 필요할 때 까지 잠시 생성을 미루어야 할 때가 있다. 프록시 패턴은 어떤 오브젝트의 접근을 가로챈 후 그 오브젝트가 놓여야 할 곳에 대신 자리를 차지함으로써, 원래 ..

[Design patterns] Facade Pattern (퍼사드 패턴)

Introduction 구조 시스템 패턴을 다루는 과정에서 패턴 이름들이 알파벳 순서로 나열되었던 게 좋았었는데 (Adapter, Bridge, Composite, Decorator), 이번엔 E로 시작하는 패턴이 나올 차례지만 안타깝게도 그런 디자인 패턴은 없다... 이번 글에서는 눈물을 머금고 알파벳 한 자리를 건너뛰어 Facade 패턴에 대해 소개하고자 한다. Facade 패턴을 한줄 요약하면 다음과 같다. 복잡한 시스템을 더 쉽게 사용하기 위한 high-level의 인터페이스를 제공한다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 아주 살짝씩 변경한 부분이 있다. Motivation 시스템을 여러 서브시스템으로 나누는 식으로 전체 시스템..

[Design patterns] Decorator Pattern (데코레이터 패턴)

Introduction 오늘 소개할 내용은 데코레이터 (Decorator) 패턴으로, 그 기능을 요약하자면 다음과 같다. 클래스 내용을 수정하지 않으면서 동적으로 오브젝트에 기능을 추가할 수 있다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 아주 살짝씩 변경한 부분이 있다. Motivation 전체 클래스 오브젝트의 동작을 수정하는 대신 특정 오브젝트에만 어떤 기능을 동적으로 추가해야 할 때가 있다. 즉, 기존에 작성된 클래스 코드를 전혀 건드리지 않으면서도 새로운 기능을 자유롭게 얼마든지 추가할 수 있으며, 기능이 추가되어도 외부에서는 기존 오브젝트와 동일하게 상호작용 할 수 있어야 한다. 코드 수정 없이 기능을 추가하기 위해 기존 클래스를 ..

[Design patterns] Composite Pattern (컴퍼짓 패턴)

Introduction GoF 디자인 패턴 중 structural pattern (구조 패턴) 들을 하나씩 다루고 있는데, 이제 한 절반쯤 왔다. 이번에 소개할 내용은 Composite 패턴으로, 한줄로 요약하자면 다음과 같다. 오브젝트를 트리 구조로 구성해 계층 구조를 표현하는 동시에, 개별 오브젝트와 오브젝트의 composition을 동일한 방식으로 다룰 수 있게 한다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 아주 살짝씩 변경한 부분이 있다. Motivation 단순한 기능을 하는 작은 오브젝트를 모아 큰 오브젝트를 구성하고, 이들을 다시 동일한 방식으로 모아 더 큰 단위의 오브젝트를 구성해야 하는 경우가 있다. 예를 들어, Point-..

[Design patterns] Bridge Pattern (브릿지 패턴)

Introduction 이번 글에서는 또다른 structural pattern (구조 패턴) 인 브릿지 패턴에 대해 소개하고자 한다. 브릿지 패턴은 인터페이스와 실제 구현을 분리해, 각각이 독립적으로 수정될 수 있도록 도와준다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 아주 살짝씩 변경한 부분이 있다. Motivation 인터페이스는 동일하게 유지한 채로, 실제 기능은 여러 가지 방식으로 구현하고 싶을 땐 다음과 같은 방법을 사용할 수 있다. 먼저 추상 클래스 (abstract class) 를 정의해 인터페이스를 설정한다 (추상화, abstraction). 이후엔, 그것을 상속하는 실체 서브클래스 (concrete subclasses) 들에선..

[Design patterns] Adapter Pattern (어댑터 패턴)

Introduction 이번 글에서는 structural pattern (구조 패턴) 중 하나인 어댑터 패턴에 대해 소개하고자 한다. 어댑터 패턴에 대해 요약하자면, 현재의 클래스 인터페이스 X를 요구되는 인터페이스인 Y로 변환해 주는 디자인 패턴이라 할 수 있다. 본 글의 많은 부분은 에릭 감마의 GoF Design Pattern 서적에서 참고했고, 파이썬에 맞추어 아주 살짝씩 변경한 부분이 있다. Motivation 재사용을 위해 작성해놓은 툴킷 클래스가, 실제로 그것을 사용하는 쪽에서 요구하는 특수한 인터페이스를 가지고 있지 않아 사용이 불가능한 경우가 있다. 이런 상황에서 여기저기서 재사용되는 기존의 툴킷 클래스의 소스 코드를 변경하지 않고 현재의 특수한 인터페이스 요구 상황에 맞추기 위해 어댑터..

[Design patterns] Singleton Pattern (싱글턴 패턴)

Introduction Design Patterns: Elements of Reusable Object-Oriented Software (1994) 의 저자인 Erich Gamma 는 책이 출판된 15년 후의 인터뷰에서 이렇게 언급한 적이 있다. Larry: How would you refactor "Design Patterns"? Erich: ... When discussing which patterns to drop, we found that we still love them all. (Not really — I'm in favor of dropping Singleton. Its use is almost always a design smell.) 의역하자면 다음과 같다. Larry: "Design P..