모든 글은 유튜브 얄팍한 코딩사전에 출처를 두고있습니다.
객체 지향의 지향점과 의미에 대해 더 이해하기 위해서,
GoF의 디자인 패턴에 대해 조금 더 공부해보기로 했다.
오늘부터 디자인 패턴을 하나씩 여기에 적어보려 한다.
Singleton
가장 처음으로, 싱글톤(Singleton) 패턴이다.
싱글톤은 간단하게 정의하면 아래와 같이 정의할 수 있다.
객체의 인스턴스를 오직 하나만 만들어서 사용하도록 한다.
우리는 보통 객체의 인스턴스를 할당할 때 생성자를 사용한다.
위와 같이 new
키워드와 함께 생성자를 통해 할당받곤 하는데,
만약 다수의 사용자가 객체를 많이 생성하게 된다면 어떨까?
서버의 메모리에 무리가 오게 될 것이다.
따라서 사용자가 많은 웹서비스 같은 경우에는 이런 방법이 필요하다.
구현
웹의 다크모드를 예시로 한 번 싱글톤 패턴을 구현해보자.
아래와 같이 어떤 웹 페이지를 다크모드로 바꾸고 싶다고 가정해보자.
하나의 페이지에서 다크모드로 변경하게 되면,
다른 페이지에도 당연히 동일하게 옵션이 적용되어야 할 것이다.
이 때, 싱글톤이 적용되지 않은 상태라면?
아래의 사진과 같이 페이지 별로 옵션이 다르게 적용이 됨을 볼 수 있다.
하지만 아래의 사진과 같이 싱글톤 패턴을 적용하도록 한다면?
각 페이지에서 new Settings()
키워드로 설정을 하는 것이 아닌,
getSettings()
메서드를 통하여 인스턴스를 할당받기 떄문에
아래와 같이 설정이 그대로 유지됨을 확인할 수 있다.
장단점
싱글톤은 장점만 보았을 때 굉장히 좋은 패턴이라고 볼 수 있다.
메모리 관점에서 유용하며, 데이터 공유도 쉽다는 점이 그렇다.
하지만 단점이 없는 것은 아니다.
다른 것들을 모두 떠나서 가장 큰 단점은 동시성
문제의 발생 가능성이다.
하나의 static
한 객체를 여러 사용자가 동시에 사용하기 때문인데,
물론 synchronized
나 volatile
예방이 가능하다.
이러한 단점 때문에 안티패턴 취급을 받기도 한다.
Spring의 Singleton
Spring은 기본적으로 객체의 생성에 있어서 Singleton 패턴이 적용된다.
물론, 위에서 언급했던 단점들을 보완한 Singleton 패턴을 제공하고 있다.
따라서 트래픽이 많은 웹 서비스에 적용하기 굉장히 적합한 프레임워크인 것이다.