[TIL] 8. 8월 디자인패턴(싱글톤, 전략패턴)

수업중 배웠던 디자인패턴에 대해 정리를 해보려고 한다

 

coffee manager라는 프로그램을 만들면서 사용된 디자인 패턴 중 우선 싱글톤 패턴을 알아보자

🧐싱글톤 패턴이란??

싱글톤 패턴은 특정 클래스의 인스턴스가 프로그램 전체에서 단 하나만 생성되도록 보장하는 디자인 패턴이다.

시스템 전체에서 유일해야 하는 개체를 관리할 때 사용된다. 이렇게 생성된 단 하나의 객체는 어디서든 동일하게 접근할 수 있는 전역적인 접근점을 가지게 된다.

 

커피매니저에서는 돈을 관리하는 계좌 클래스(Account class)를 싱글톤 패턴으로 구성했다.

🧐왜 그렇게 구성했을까?

커피매니저에서 계좌 클래스는 매출, 지출, 잔고등을 관리하는 커피매니저만의 계좌다,

그냥 생성했을 경우 vs 싱글톤으로 생성했을 때 차이

그런데 새로운 인스턴스를 생성해서 사용한다면 커피를 판매했을 때는 계좌 클래스의 A인스턴스에 저장되고 지출이 발생했을 때는 B인스턴스에 저장된다면 정보들이 제각각으로 분리되어서 계좌의 역할을 충실히 다하지 못한다.

 

이때 우리는 공통된 계좌가 필요함을 느낄 수 있다. 그래서 싱글톤으로 해당 클래스를 구성한다면 언제 어디서든 유일한 계좌에 접근할 수 있어서 커피매니저의 계좌의 역할 충실히 수행할 수 있다.

코드로 보는 싱글톤 패턴

 

 

해당 코드를 보면 생성자 부분은 private로 접근할 수 없게 작성이 되어있다. public으로 생성자가 공개되어있다면 어디서든 새로운 인스턴스를 생성할 수 있다, 즉 하나의 계좌만 유일하게 존재해야한다는 원칙을 깨버리게 된다 그래서 생성자는 private로 막아놓고 대신에 getInstance라는 메서드를 통해서 해당 인스턴스에 접근할 수 있게 구성이 되어있다.

🧐Strategy 패턴

이번에는 Strategy 패턴 (전략 패턴이다)

커피매니저에서는 할인 정책을 적용할 때 사용되었는데 전략패턴을 사용하지 사용하지 않았다면

만약 새로운 if-else 문으로 어떤 할인방법이 적용되어야 하는지 비교해야될것이다 그리고 이 할인 방법들이 늘어날수록 기존 코드를 수정해야하고 복잡해져서 유지보수는 물론이고 기능추가도 힘들고 실수도 할 확률이 커진다. 그리고 하나의 클래스가 너무 많은 책임을 지게 된다.

할인 조건이 늘어날 수록 if-else문은 늘어난다

또 SOLID 원칙 중 O에 해당하는 OCP 원칙을 위반하는 사례이다.

OCP(Open-Closed Principle) 원칙을 간단하게 설명하자면 기능 확장에는 열려있고 수정에 대해서는 닫혀있다는 뜻이다.

 

전략 패턴의 핵심은 변하는 것(할인 정책)과 변하지 않는 것(결제 로직)을 분리하는 것이다.

Context (전략을 사용하는 클라이언트): Payment 클래스

Strategy (전략의 규칙 또는 설계도 - 공통 인터페이스 or 추상클래스): DiscountPolicy 클래스

Concrete Strategy (실제 전략들 인터페이스를 구현하는 클래스): AmountDiscountPolicy, PercventDiscountPolicy 클래스

 

 

Payment 클래스는 할인정책인 DiscountPolicy를 주입 받아서 사용한다, 즉 Payment클래스는 어떤 할인정책이 들어올지 모른다는 상태이다. 단지 discountPolicy에게 calculatePaymentPrice() 를 실행하라고 명령할 뿐이다.

😎또 다른 전략

수업에서는 여기서 또 한가지 방식을 더 추가했다 바로 특정한 조건에 만족할 때 할인을 적용하는 것이다.

무조건 할인을 적용해주는것이 아니라 주문 금액이 일정 금액 이상이거나, 오전에 결제를 하거나 등등 특정한 조건에 만족할 때 할인을 적용하기 위해 추가적으로 전략패턴을 사용했다

방식은 할인정책을 적용했을 때와 같다 DiscountCondition에는 해당 조건의 규칙으로 "이 주문이 해당 조건에 만족하는지?"를 묻는 isSatisfied 메서드를 정의했다. 아래의 OrderPrice, Period Condition은 주문금액, 특정요일을 검사하는 실제 구현체들이다.

 

그렇다면 두 패턴이 어떻게 함께 적용되는지 코드를 통해 확인해보자

해당 코드는 AmountDiscountPolicy클래스의 코드인데 모든 할인 조건을 순회하면서 만족하는 조건이 존재한다면 그 조건에 해당하는 할인을 적용하는 메서드이다.

이렇게 '어떻게' 할인 할 것인지 그리고 '언제' 할인 할 것인지 각각 독립적으로 확장할 수 있는 구조가 완성되었다.

 

이렇게 상황에 맞게 디자인패턴을 사용한다면 미래의 변경에 유연하게 대처할 수 있고 유지보수하기 용이할것이다.