싱글톤 (Signleton)
싱글톤 패턴은 단 하나의 인스턴스를 생성해 사용하는 디자인 패턴이다.
코드 내 어디서든, 오직 하나의 인스턴스만 사용할 수 있도록 객체를 생성하는 방법이다.
즉 객체는 여러 번 생성되지 않고, 최초 하나의(Single) 인스턴스만 생성하고, 이후에는 이 인스턴스를 참조하게 된다.
전역적으로 하나의 인스턴스만 사용, 참조해야하는 경우에 사용한다.
장점
하나의 인스턴스를 사용 -> 메모리 낭비를 방지할 수 있음
전역 인스턴스 -> 다른 클래스의 인스턴스들이 데이터를 공유
단점
싱글톤 인스턴스가 너무 많은 일을 하거나 많은 데이터를 공유시킬 경우,
SOLID 원칙 중 SRP, OCP 원칙에 위배됨.
즉, 수정과 테스트가 어려워짐
꼭 필요한 경우아니면 지양해야 함
활용 상황
공통된 객체를 여러 개 생성해서 사용해야하는 상황
전역에서 사용될 하나의 객체를 만들어야하는 상황(시스템 전역의 로깅을 담당하는 로거)
DB 커넥션과 Pool 을 담당하는 인스턴스
구조
# 보통, 싱글톤 객체의 .get_instance() 로 인스턴스를 받아온다.
singleton_1 = Singleton.get_instance()
singleton_2 = Singleton.get_instance()
# 이렇게 받아온 두 인스턴스는 동일한 인스턴스다.
singleton_1 == singleton_2 # True프로토타입 (Prototype)
기존의 인스턴스를 그대로 복제(clone) 하여 새로운 객체를 생성하는 방법이다.
즉, 하나의 인스턴스를 사용하는 싱글톤과는 반대되는 개념이다.
구조
활용 예시
DB 로부터 얻어온 데이터 인스턴스를 동일하게 하나 더 만들어야 하는 경우 (DB 에 연결하는 것 보다 이렇게 코드로 처리 하는게 일반적으로 cost 가 더 저렴하다.)
# 보통, 프로토타입 객체의 .clone() 으로 인스턴스를 복사한다.
original = Prototype()
prototype = original.clone()
# 이렇게 받아온 두 인스턴스는 동일한 객체는 아니지만, 내부 데이터는 같다.
original == prototype # False
original.data == prototype.data # True팩토리 (Factory)
인스턴스를 만들어내는 공장(Factory) 를 통해 객체를 생성하는 방법이다.
즉, 인스턴스를 직접 생성해내지 않고, 공장에서 제공하는 메쏘드를 통해 생성해낸다.
사용자는 객체를 생성하고 싶을 때, 공장에서 제공하는 메쏘드만 알고있으면 된다.
그 외 구체적으로 인스턴스가 어떻게 생성되는지 몰라도 된다.
한 집합 내에 있는 클래스들의 생성을 한 곳에서 처리하고 싶을 때 사용한다.
장점
- 객체 생성 하는 코드를 분리하여 클라이언트 코드와 결합도(의존성)를 낮춤.
- 코드에 변경이 필요할 시, 객체 생성 클래스만 수정하면 된다.
- 인터페이스를 바탕으로 유연성과 확장성이 뛰어난 코드 제작이 가능
- 객체의 자료형이 하위 클래스 의해서 결정됨
- 확장에 용이함
- 상위 클래스에서 그 객체에 대한 정확한 타입을 몰라도 된다.
- SOLID 원칙 중 DIP (Dependency Inversion Principle, 의존 관계 역전 원칙) 를 성립함
단점
- 새로 생성할 객체의 종류가 늘어날 때마다, 클래스가 많아짐.
활용예시
개념 상 같은 분류의 클래스들의 생성을 모아서 처리하는게 편할 때
구조
추상 팩토리 (Abstract Factory)
공장을 만들어내는 상위 공장을 먼저 정의하고, 여기서 구체적인 공장을 만든 후, 이 공장에서 객체를 생성하는 방법이다.
즉, 팩토리의 위에 이 팩토리를 만드는 팩토리가 있다고 생각하면 된다.
추상 팩토리 메쏘드는, 기존 팩토리 메쏘드 방식에서
팩토리의 상위 팩토리를 통해 구체적인 팩토리를 생성한다.
그 외 특징은 팩토리 패턴과 같다.
빌더 (Builder)
객체를 생성할 때 필요한 파라미터가 많은 경우, 각 파라미터가 무엇을 의미하는지 알기 힘들 수 있다.
이럴 때, 빌더라는 형태를 통해 파라미터 의미를 명확히하여 생성할 수 있다.
빌더 패턴은 생성 인자가 많을 시,
빌더 객체를 통해 구체적인 객체를 생성한다.
장점
- 객체 생성에 필요한 파라미터의 의미를 코드 단에서 명확히 알 수 있다. (가독성이 좋다.)
- 생성에 필요한 파라미터가 추가될 때 마다, 생성자 오버로딩을 안해도 된다.
단점
- 추가적인 빌더 클래스 구현해야 함.
활용 상황
- 생성자 인자가 많은 경우.
