[디자인 패턴] 싱글톤 패턴 / 팩토리 패턴 / 전략 패턴 / 옵저버 패턴

본 포스팅은 [면접을 위한 CS 전공지식 노트]의 내용을 참고하여 작성하였습니다.

1.1 디자인 패턴

프로그램을 설계할 때 발생했던 문제점들을, 객체 간의 상호 관계를 이용하여 해결할 수 있도록 '규약' 형태로 만든 것이다.

하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이다.

보통 데이터베이스 연결 모듈에 많이 활용된다.

하나의 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에, 인스턴스를 생성할 때 드는 비용이 줄어드는 장점이 있다.

하지만 의존성이 높아진다는 단점이 있다.

싱글톤 패턴은 TDD(Test Driven Developmenet)를 할 때 문제가 된다. TDD를 할 때 단위 테스트를 주로 하는데, 단위 테스트는 서로 독립적이어야 하며 어떤 순서로든 실행할 수 있어야 한다.

하지만 싱글톤 패턴은 하나의 인스턴스를 기반으로 구현하는 패턴이므로, 각 테스트마다 독립적인 인스턴스를 만들기 어렵다.

또한, 싱글톤 패턴은 사용하기 쉽고 실용적이지만 모듈간의 결합을 강하게 만든다는 단점이 있다. 이 때 의존성 주입(DI, Dependency Injection)을 통해 모듈간의 결합을 느슨하게 만들어 해결할 수 있다.

객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴이다.

상속 관계에 있는 두 클래스에서 상위 클래스가 뼈대를, 하위 클래스가 객체 생성에 관한 구체적인 내용을 결정한다.

상위 클래스와 하위 클래스가 분리되기 때문에 느슨한 결합을 가지며, 객체 생성 로직이 따로 분리되어 있기 때문에 유지 보수에 용이하다.

정책 패턴이라고도 하며, 객체의 행위를 바꿀 때 직접 수정하는 대신 캡슐화한 알고리즘(=전략)을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴이다.

주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 일어나면 메서드 등을 통해 옵저버 목록에 있는 옵저버에게 변화를 알려주는 디자인 패턴이다.

주체란 객체의 상태 변화를 보고 있는 관찰자이며, 옵저버란 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 추가 변화 사항이 생기는 객체들을 의미한다. 또한, 주체와 객체를 따로 두지 않고 상태가 변경되는 객체를 기반으로 구축하기도 한다.

옵저버 패턴은 주로 이벤트 기반 시스템에 사용하며 MVC 패턴에도 사용된다. (주체라고 볼 수 있는 Model에 변경사항이 생겨 옵저버인 View에 알려주고, 이를 기반으로 Controller가 작동)