생성 패턴(Creational Patterns) | 싱글톤(Singleton) 패턴
[index]
1. 싱글톤(Singleton) 패턴이란?
2. 싱글톤 패턴의 장점
3. 싱글톤 패턴의 단점
4. 싱글톤 패턴 적용 예시
5. 마무리
+ 디자인 패턴이 무엇인지 모른다면?
https://reveur1996.tistory.com/149
1. 싱글톤(Singleton) 패턴이란?
싱글톤(Singleton) 패턴은 하나의 클래스에 대해 오직 하나의 인스턴스만 생성하도록 하는 디자인 패턴으로, 이 인스턴스에 대한 전역 접근 지점을 제공합니다. 주로 데이터베이스 연결 모듈과 같이 여러 부분에서 단일한 자원을 공유하고자 할 때 활용됩니다. 싱글톤 패턴은 메모리를 절약하고 성능을 향상시키기 위해 사용됩니다. 여러 모듈에서 동일한 인스턴스를 공유함으로써 인스턴스를 반복적으로 생성하는 비용을 줄일 수 있습니다. 이는 특히 인스턴스 생성에 많은 비용이 드는 경우에 유용합니다. 전역 변수와의 연관성은 해당 인스턴스를 전역적으로 접근할 수 있게 하기 위함입니다. 전역 변수를 사용함으로써 어디서든 해당 인스턴스에 접근하여 사용할 수 있습니다. 이는 똑같은 데이터를 메서드마다 지역 변수로 선언하는 것보다 효율적이며 메모리를 절약할 수 있습니다.
싱글톤 패턴의 장점은 메모리 절약, 성능 향상, 전역적인 접근성이며, 단점으로는 의존성이 높아질 수 있다는 점이 있습니다. 이는 인스턴스가 전역적으로 공유되기 때문에 다른 모듈들 간의 의존성이 높아질 수 있습니다. 따라서 싱글톤을 적절히 사용하여 의존성을 최소화하고 모듈 간의 결합을 유연하게 관리하는 것이 중요합니다.
2. 싱글톤 패턴의 장점
싱글톤 패턴은 하나의 클래스 인스턴스가 전체 애플리케이션에서 오직 하나만 존재하도록 보장하는 디자인 패턴입니다. 이 패턴의 주요 장점은 다음과 같습니다
- 유일한 인스턴스 유지
싱글톤 패턴은 애플리케이션 전체에서 단일한 인스턴스만을 유지합니다. 이는 특정 리소스나 설정을 하나의 인스턴스에서 효율적으로 관리할 수 있도록 해줍니다. - 전역 접근성
싱글톤은 어디서든지 쉽게 접근할 수 있습니다. 이는 전역적인 상태나 기능을 공유하고자 할 때 유용하며, 복잡한 의존성 주입이나 인스턴스 생성을 피할 수 있습니다. - 인스턴스 생성 및 소멸 관리
싱글톤 패턴을 통해 인스턴스의 생성과 소멸을 효율적으로 관리할 수 있습니다. 인스턴스가 한 번 생성되면 애플리케이션이 종료될 때까지 메모리에 유지됩니다. - 자원 공유
여러 부분에서 동일한 인스턴스를 사용함으로써 자원을 공유할 수 있습니다. 이는 메모리나 연산 등의 자원을 효율적으로 활용할 수 있도록 도와줍니다. - 코드 일관성 유지
싱글톤 패턴을 사용하면 전역적으로 사용되는 객체에 대한 일관된 접근 방식을 갖게 됩니다. 이는 코드의 가독성과 유지보수성을 향상시키는 데 도움이 됩니다. - 지연 초기화
필요한 경우에만 인스턴스를 생성하도록 설계할 수 있어, 애플리케이션이 시작될 때 모든 리소스를 즉시 할당하지 않고 필요할 때 생성할 수 있습니다.
3. 싱글톤 패턴의 단점
- 모듈 간 의존성과 결합도 증가
대다수의 싱글톤은 클래스의 객체를 미리 생성하고 정적 메소드를 이용해 사용하기 때문에 모듈 간 의존성이 높아지고, 클래스 간 결합도가 증가합니다. 이는 싱글톤 인스턴스의 변경이 모듈에 영향을 미치며, 결국 유연성을 감소시킵니다. - SOLID 원칙 위배
싱글톤은 단일 인스턴스가 여러 책임을 가질 가능성이 높아, 단일 책임 원칙(SRP)을 위배할 수 있습니다. 또한 의존 역전 원칙(DIP)과 개방-폐쇄 원칙(OCP)을 위배할 수 있습니다. - 테스트 어려움
싱글톤은 자원을 공유하므로 테스트가 어려워집니다. 특히 TDD(Test-Driven Development)에서는 독립적인 테스트가 중요한데, 싱글톤은 이를 어렵게 만들 수 있습니다. TDD를 할 때 단위 테스트를 주로 하는데 단위 테스트는 테스트가 서로 독립적이어야 하며 테스트를 어떤 순서로든 실행할 수 있어야 합니다. 하지만 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이므로 각 테스트마다 독립적인 인스턴스를 만들기가 어렵습니다. - 멀티스레드 환경 문제
멀티스레드 환경에서 동기화 처리를 하지 않으면 인스턴스가 두 번 생성될 수 있습니다. 이로 인해 예기치 못한 동작이 발생할 수 있습니다.
단점을 보완하는 방법 | 의존성 주입(Dependency Injection)
싱글톤 패턴은 모듈 간의 결합을 강화하는 단점이 있습니다. 이러한 결합을 완화하고 모듈 간의 유연성을 높이기 위해 의존성 주입(Dependency Injection, DI)이 사용됩니다. DI는 모듈 간의 직접적인 의존성을 해소하고, 중간에서 의존성 주입자(DI 컨테이너 등)가 의존성을 주입하는 방식입니다. DI를 적용할 때는 몇 가지 원칙을 따라야 합니다. 메인 모듈은 하위 모듈에서 아무 것도 가져오지 않아야 하며, 둘 다 추상화에 의존해야 합니다. 이때 추상화는 세부 사항에 의존하지 않도록 설계되어야 합니다. DI를 통해 모듈들을 쉽게 교체하고 테스트하기 용이한 구조를 만들 수 있습니다. 또한 추상화 레이어를 통해 애플리케이션의 의존성 방향이 명확해지고 모듈 간의 관계가 명시적으로 드러납니다. 하지만 의존성 주입은 모듈들을 더 분리시켜 클래스 수가 증가하고, 복잡성이 증가할 수 있습니다. 또한 약간의 런타임 성능 손실이 발생할 수 있습니다. 따라서 의존성 주입을 적용할 때는 이러한 단점을 고려하여 적절한 설계를 해야 합니다.
4. 싱글톤 패턴 적용 예시
let Singleton = (function () {
// 인스턴스 저장 변수
let instance;
// 생성자 함수
function SingletonClass() {
// 싱글톤 클래스의 내용 정의
this.name = "Singleton Instance";
this.method = function () {
console.log("Method inside Singleton");
};
}
// 싱글톤 인스턴스를 생성하고 반환하는 함수
function createInstance() {
return new SingletonClass();
}
// 인스턴스가 존재하지 않으면 생성하고, 존재하면 기존 인스턴스 반환
return {
getInstance: function () {
if (!instance) {
instance = createInstance();
}
return instance;
},
};
})();
// 테스트
let instance1 = Singleton.getInstance();
let instance2 = Singleton.getInstance();
console.log(instance1 === instance2); // true, 같은 인스턴스를 반환
console.log(instance1.name); // "Singleton Instance"
instance1.method(); // "Method inside Singleton"
5. 마무리
싱글톤 패턴은 객체 지향 프로그래밍의 기본 원칙을 어기는 경향이 있어 안티 패턴으로 불리고 있습니다. 이 패턴은 특히 강력한 결합과 낮은 유연성으로 인해 싱글톤 패턴이 가지는 효율성은 특정 상황에서만 유효하며, 그 남용은 객체 지향 설계 원칙을 위배하고 코드의 유연성 및 테스트 가능성을 저하시킬 수 있습니다. 따라서 스프링 컨테이너와 같은 프레임워크의 도움을 받아 싱글톤 패턴의 단점을 보완하고 이점을 최대한 살리는 것이 권장됩니다. 프레임워크 없이 싱글톤 패턴을 사용하려면 장단점의 trade-off를 신중하게 고려해야 합니다. 싱글톤 패턴의 특성을 이해하고, 한계와 문제점을 인지하며 사용하는 것이 중요합니다. 이렇게 신중하게 판단하여 싱글톤 패턴을 적절히 활용하면 코드의 효율성을 높일 수 있습니다.
참고문헌
https://www.zerocho.com/category/JavaScript/post/57541bef7dfff917002c4e86
https://gyoogle.dev/blog/design-pattern/Singleton%20Pattern.html
'Web Development > Design Patterns' 카테고리의 다른 글
[Design Patterns] 구조 패턴(Structural Patterns) | 프록시 (Proxy) 패턴 (0) | 2023.12.12 |
---|---|
[Design Patterns] 행위 패턴(Behavioral Patterns) | 옵저버(Observer) 패턴 (0) | 2023.12.12 |
[Design Patterns] 행위 패턴(Behavioral Patterns) | 전략 (Strategy) 패턴. (0) | 2023.12.12 |
[Design Patterns] 생성 패턴(Creational Patterns) | 팩토리 메서드 (Factory Method) 패턴 (0) | 2023.12.11 |
[디자인 패턴] 디자인 패턴이란? (0) | 2023.12.10 |