[CS]디자인 패턴

싱글톤 패턴

• 클래스에 오직 하나의 객체만이 생성됨을 보장
• 오직 하나의 인스턴스만을 생성하여 이를 접근하는 메소드를 제공

 

주로 언제 사용하는가?

💡 공통된 객체를 여러개 생성해서 사용해야하는 상황
💡 `데이터베이스에서 커넥션풀, 스레드풀, 캐시, 로그 기록 객체 등`

 

장단점

+) 메모리 측면의 효율성 : 최초 한번의 new 연산자를 통해서 고정된 메모리 영역을 사용 → 추후 해당 객체 접근 시 메모리 낭비를 방지

+) 데이터 공유 수월: 싱글톤 인스턴스가 전역으로 사용되는 인스턴스 → 다른 클래스의 인스턴스들이 접근하여 사용할 수 있음

-) 테스트의 어려움 : 싱글톤 인스턴스는 자원을 공유하고 있음 → 테스트가 결정적으로 격리된 환경에서 수행하기 위해서는 매번 인스턴스의 상태를 초기화 시켜줘야함

-) 개방-폐쇄 원칙 위배 : 싱글톤 인스턴스가 혼자 많은 일 , 많은 데이터 공유 → 다른 클래스들 간의 결합도가 높아짐

---

 

 

팩토리 패턴

: 클래스의 인스턴스를 만드는 일을 서브 클래스에게 맡김

주로 언제 사용하는가?

💡  어떤 클래스가 자신이 생성해야 하는 객체의 클래스를 예측할 수 없을 때 ,
💡 생성할 객체를 기술하는 책임을 자신의 서브클래스가 지정했으면 할 때

 

장단점

+) 수정에 닫혀있고 확장에는 열려있는 OCP 원칙을 지킬 수 있다는 점

-) 간단한 기능을 사용할 떄보다 많은 클래스를 정의해야 하기 때문에 코드량 증가

---

 

 

전략 패턴

: 객체가 할 수 있는 행위들 각각을 전략으로 만들어 놓고, 동적으로 행위의 수정이 필요한 경우 전략을 바꾸는 것만으로 행위의 수정이 가능하도록 만든 패턴

주로 언제 사용하는가?

💡 **`if-else`** 코드 블럭으로 구성되어 있는데, 모든 코드가 비슷한 기능을 수행하는 경우
💡 알고리즘의 동작이 런타임에 실시간으로 교체 되어야할 때
💡 알고리즘 코드가 노출되어서는 안 되는 데이터에 엑세스 하거나 데이터를 활용할 때 (캡슐화) 

 

장단점

-) 알고리즘이 많아질 수록 관리해야하는 객체의 수가 늘어날 수 있음

-) 개발자는 적절한 전략을 선택하기 위해서는 전략 간의 차이점을 파악하고 있어야함 (복잡도 상승)

참고:

💠 전략(Strategy) 패턴 - 완벽 마스터하기

---

 

옵저버 패턴

어떤 객체의 변경 사항이 발생하였을때 이와 연관된 객체들에게 알려주는 디자인 패턴

주로 언제 사용하는가?

💡 **일대다(one-to-many) 의존성**을 가지는데, 주로 분산 이벤트 핸들링 시스템을 구현하는 데 사용
💡  pub/sub(발행/구독) 모델로도 알려져 있음

장단점

+) 실시간으로 한 객체의 변경사항을 다른 객체에 전파 할 수 있음

+) 느슨한 결합으로 시스템이 유연하고 객체간의 의존성을 제거할 수 있음

 

-) 너무 많이 사용하면, 상태 관리 힘듦

-) 데이터 분배에 문제가 생기면 큰 문제로 이어질 수 있음

 

참고:

[iOS]옵저버 패턴(Observer Pattern)

---

 

프록시 패턴

: 대상 원본 객체를 대리하여 대신 처리하게 함으로써 로직의 흐름을 제어하는 행동 패턴

→ 대상 객체의 메소드를 직접 실행하는 것이 아닌, 대상 객체에 접근하기 전에 프록시 객체의 메서드를 접근한 후 추가적인 로직을 처리한 뒤 접근

주로 언제 사용하는가?

💡 대상 클래스가 민감한 정보를 가지고 있거나 인스턴스화 하기에 무겁고 추가 기능을 가미하고 싶을 때
💡  원본 객체를 수정할 수 없는 상황을 극복하기 위함

 

장단점

+) 개방-폐쇄 원칙을 준수 : 기존 대상 객체의 코드를 변경하지 않고 새로운 기능을 추가할 수 있음

+) 단일 책임 원칙 준수 : 대상 객체는 자신의 기능에만 집중 → 다중 책임을 회피

 

-) 프록시 클래스 자체에 들어가는 자원이 많다면 서비스로부터 응답이 느려질 수 있음

---

 

질문 리스트

1. 싱글톤 패턴을 사용하는 이유는?

모든 데이터를 전역으로 관리하기 때문에 쉽게 접근할 수 있고, 초기 객체를 생성하게 되면 정적 메모리에 올라가기 때문에 호출이 빠름. 중복 생성과 메모리 낭비를 방지할 수 있다.

2. 디자인 패턴을 사용하는 이유는?

협업 시 범용적인 코딩 스타일을 적용할 수 있음

인수인계 등 → 소프트웨어 구조 파악에 용이

요구사항 수시로 변경 : 요구사항에 따른 소스 코드 변경을 최소화할 수 있게 해줌, 유연한 대처 가능