객체지향 디자인 패턴 - Singleton, Strategy, State pattern

Singleton pattern

• 생성자가 여러 번 호출되더라도 실제 생성되는 객체는 하나가 되는 방식 / 최초에 한번 생성된 이후 다시 생성자를 호출하더라도 기존에 생성되어있던 객체를 반환
• 클래스에서 만들 수 있는 인스턴스의 수를 하나로 제한, 이 객체에 전역적으로 접근이 가능하고 다른 클래스 간 데이터 공유가 용이
• 동일 클래스에 대해 여러개의 인스턴스를 생성하지 않기 때문에 메모리 낭비를 방지

멀티 스레드 환경에서 하나의 객체 생성이 보장되지 않을 수 있기에 lock 등 통하여 이를 보장해주어야 한다.

 

 

 

Strategy pattern

• 객체들이 할 수 있는 행위 각각에 대해 전략 클래스를 생성하고, 유사한 행위들을 캡슐화하는 인터페이스를 정의하여, 객체의 행위를 동적으로 바꾸고 싶은 경우 직접 행위를 수정하지 않고 전략을 바꿔주기만 함으로써 행위를 유연하게 확장하는 방법

언제 사용?
1. 전략 알고리즘의 여러 버전 또는 변형이 필요할 때 클래스화를 통해 관리
2. 알고리즘 코드가 노출되어서는 안되는 데이터에 액세스하거나 데이터를 활용할 때
3. 알고리즘의 동작이 런타임에 실시간으로 교체 되어야 할 때

• 알고리즘이 많아질수록 관리해야할 객체 수가 늘어남
• 어플리케이션 특성이 알고리즘이 많지 않고 자주 변경되지 않는다면, 새로운 클래스와 인터페이스를 만들어 프로그램을 복잡하게 만들 이유가 없음
• 개발자는 적절한 전략을 선택하기 위해 전략 간의 차이점을 파악하고 있어야함.

 

 

State Pattern

• 상태패턴은 객체가 특정 상태에 따라 행위를 달리하는 상황에서, 상태를 조건문으로 검사해서 행위를 달리하는 것이 아닌, 상태를 객체화하여 상태가 행동을 할 수 있도록 하는 패턴
• 같은 상태에 대한 모든 동작과 데이터를 클래스 하나에 캡슐화하는 패턴이다.

언제 사용??
1. 객체의 행동이 상태에 따라 달라질 수 있고, 객체의 상태에 따라 런타임에 행동이 바뀌어야 하는 경우
2. 객체의 행동이 상태에 영향을 받으며, 상태 간 전환이 명시적인 경우
3. 현재 상태에 따라 다르게 동작하는 객체가 있고 상태의 수가 많이 있고 상태별 코드가 자주 변경되는 경우
4. 중복 코드가 많은 경우