Design pattern

“바퀴를 다시 발명하지 마라(Don’t reinvent the wheel)”
이미 만들어져서 잘 되는 것을 처음부터 다시 만들 필요가 없다는 의미이다.

디자인 패턴은 소프트웨어 공학론 안의 좋은 코드를 설계하기 위한 일종의 설계 디자인 방법론이다.

좋은 코드란 가독성,간결함 등 여러 방면이 있지만, 디자인 패턴에서는 설계적 관점에서의 좋은 코드를 말한다.

디자인 패턴은 의사소통 수단의 일종으로서 문제를 해결해준다.

예를 들어 문제 해결의 제안에 있어서도 “기능마다 별도의 클래스를 만들고, 그 기능들로 해야할 일을 한번에 처리해주는 클래스를 만들자.”라고 제안하는 것보다"Facade 패턴을 써보자."라고 제안하는 쪽이 이해하기 쉽다.

디자인 패턴의 종류

1. 생성 패턴

특정 객체가 생성되고 변경되어도 전체 시스템의 변화는 초소화되도록 만들어 주어, 시스템의 확장이나 유지보수시 최소 비용이 들도록 만들어 준다.

1-1. 싱글톤(singleton)

소프트웨어 디자인 패턴에서 싱글톤 패턴(Singleton pattern)을 따르는 클래스는, 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다. 이와 같은 디자인 유형을 싱글톤 패턴이라고 한다. (파이썬 모듈이 싱글톤)

쓰는 이유

• 고정된 메모리 영역을 얻으면서 한번의 new로 인스턴스를 사용하기 때문에 메모리 낭비를 방지할 수 있음
• 또한 싱글톤으로 만들어진 클래스의 인스턴스는 전역 인스턴스이기 때문에 다른 클래스의 인스턴스들이 데이터를 공유하기 쉽다.
• 인스턴스가 절대적으로 한개만 존재하는 것을 보증하고 싶을 경우 사용.
• 두 번째 이용시부터는 객체 로딩 시간이 현저하게 줄어 성능이 좋아지는 장점!

문제점

• 싱글톤 인스턴스가 너무 많은 일을 하거나 많은 데이터를 공유시킬 경우 다른 클래스의 인스턴스들 간에 결합도가 높아져 "개방-폐쇄 원칙" 을 위배하게 된다. (=객체 지향 설계 원칙에 어긋남)
• 따라서 수정이 어려워지고 테스트하기 어려워진다.

= 적절히 잘 써야 좋다.

2. 구조 패턴

여러 클래스들로 이루어진 복잡한 구조를 가진 시스템의 효율적인 개발을 위해 구조를 분산하여 새로운 기능의 추가를 효과적으로 할 수 있도록 하는 패턴.
클래스나 객체를 조합해 더 큰 구조를 만드는 패턴.

2-1 데코레이터(decorator)

객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 해주는 패턴

쓰는 이유

• 객체에 동적으로 기능 추가가 간단하게 가능하다.
• 기존 코드를 수정 하지 않아도 된다.

문제점

• 자잘한 데코레이터 클래스들이 계속 추가되어 클래스가 많아질 수 있다.
• 많이 사용하면 코드가 필요 이상으로 복잡해진다.

3. 행동 패턴

객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴이다.
한 객체가 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하며 객체 사이의 결합도 최소화에 중점을 둔다.

3-1 옵저버(observer)

객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다.
주로 분산 이벤트 핸들링 시스템을 구현하는 데 사용된다.

쓰는 이유

• 실시간으로 한 객체의 변경사항을 다른 객체에 전파할 수 있다.
• 느슨한 결합으로 시스템이 유연하고 객체간의 의존성을 제거할 수 있다.

문제점

• 너무 많이 사용하게 되면, 상태 관리가 힘들 수 있다.
• 데이터 배분에 문제가 생기면 자칫 큰 문제로 이어질 수 있다.