서비스 로케이터 패턴
서비스 로케이터 패턴(service locator pattern)은 소프트웨어 개발에서 강한 추상화 계층을 통해 서비스를 얻는 것과 관련된 프로세스를 캡슐화하는 데 사용되는 디자인 패턴이다. 이 패턴은 "서비스 로케이터"라고 불리는 중앙 레지스트리를 사용하며, 요청이 들어오면 특정 작업을 수행하는 데 필요한 정보를 반환한다.[1] 이 패턴의 지지자들은 모든 의존성이 전체 애플리케이션 설계의 시작 부분에 깔끔하게 나열되는 컴포넌트 기반 애플리케이션에서 접근 방식이 단순해지며, 결과적으로 전통적인 의존성 주입이 객체를 연결하는 더 복잡한 방법이 될 수 있다고 말한다. 반면 비판론자들은 이 패턴이 의존성을 모호하게 만들고 소프트웨어 테스트를 어렵게 만드는 안티패턴이라고 주장한다.[2]
장점
[편집]- "서비스 로케이터"는 간단한 실행 시간 링커 역할을 할 수 있다. 이를 통해 애플리케이션을 다시 컴파일하지 않고도 실행 시간에 코드를 추가할 수 있으며, 어떤 경우에는 애플리케이션을 재시작하지 않아도 된다.
- 애플리케이션은 서비스 로케이터에서 항목을 선택적으로 추가하거나 제거함으로써 실행 시간에 스스로를 최적화할 수 있다. 예를 들어, 애플리케이션이 기본 라이브러리보다 JPG 이미지를 읽는 데 더 나은 라이브러리가 있음을 감지하고 그에 따라 레지스트리를 변경할 수 있다.
- 라이브러리나 애플리케이션의 큰 부분을 완전히 분리할 수 있다. 이들 사이의 유일한 연결 고리는 레지스트리가 된다.
- 애플리케이션은 특정 기능이나 테스트를 목적으로 하는 구조화된 서비스 로케이터를 여러 개 사용할 수 있다. 서비스 로케이터는 프로세스당 하나의 단일 정적 클래스를 강제하지 않는다.
- 잘 구조화된 컴포넌트/서비스 설계를 갖춘 애플리케이션의 경우 의존성 주입보다 서비스 로케이터를 사용하는 솔루션이 더 단순할 수 있다. 이러한 경우 단점은 오히려 장점으로 간주될 수 있다(예: 모든 클래스에 다양한 의존성을 제공하고 의존성 구성을 유지 관리할 필요가 없음).
- 서비스 위치 확인 프로세스는 특정 비즈니스 사례를 나타낼 수 있는 호출 범위/컨텍스트에 민감하게 만들 수 있다. 일반적으로 생성자 매개변수 전달을 통해 객체에 의존성을 공급하는 고정된 DI에 의존하는 대신, 필요에 따라 비즈니스 컨텍스트 내에서 서비스 위치 호출을 수행할 수 있다. 예를 들어, 서비스 로케이터 호출을 통해 얻은 "IShippingStrategy" 인스턴스를 호출하면서 무엇이 어디서 어디로 배송되는지를 명시하는 "ShippingContext"를 서비스 로케이터에 매개변수로 전달하여 서비스 로케이터가 최상의 사례(예: 패턴 매치 점수 사용)를 일치시키도록 할 수 있다. 이는 실행 시간에 동적으로 위치한 최적의 매칭 전략의 점수화를 통해 복잡한 의사결정이 이루어질 수 있는 복잡한 비즈니스 애플리케이션 아키텍처(예: 의료 스코어링 시스템, 라우팅)를 크게 단순화한다.
단점
[편집]같이 보기
[편집]각주
[편집]- ↑ Fowler, Martin. “Inversion of Control Containers and the Dependency Injection pattern”.
- ↑ Seemann, Mark. “Service Locator is an Anti-Pattern” (영어). 《blog.ploeh.dk》. 2017년 6월 1일에 확인함.
