서비스 로케이터 패턴

서비스 로케이터 패턴(service locator pattern)은 소프트웨어 개발에서 강한 추상화 계층을 통해 서비스를 얻는 것과 관련된 프로세스를 캡슐화하는 데 사용되는 디자인 패턴이다. 이 패턴은 "서비스 로케이터"라고 불리는 중앙 레지스트리를 사용하며, 요청이 들어오면 특정 작업을 수행하는 데 필요한 정보를 반환한다. 이 패턴의 지지자들은 모든 의존성이 전체 애플리케이션 설계의 시작 부분에 깔끔하게 나열되는 컴포넌트 기반 애플리케이션에서 접근 방식이 단순해지며, 결과적으로 전통적인 의존성 주입이 객체를 연결하는 더 복잡한 방법이 될 수 있다고 말한다. 반면 비판론자들은 이 패턴이 의존성을 모호하게 만들고 소프트웨어 테스트를 어렵게 만드는 안티패턴이라고 주장한다.

 장점 
 "서비스 로케이터"는 간단한 실행 시간 링커 역할을 할 수 있다. 이를 통해 애플리케이션을 다시 컴파일하지 않고도 실행 시간에 코드를 추가할 수 있으며, 어떤 경우에는 애플리케이션을 재시작하지 않아도 된다.
 애플리케이션은 서비스 로케이터에서 항목을 선택적으로 추가하거나 제거함으로써 실행 시간에 스스로를 최적화할 수 있다. 예를 들어, 애플리케이션이 기본 라이브러리보다 JPG 이미지를 읽는 데 더 나은 라이브러리가 있음을 감지하고 그에 따라 레지스트리를 변경할 수 있다.
 라이브러리나 애플리케이션의 큰 부분을 완전히 분리할 수 있다. 이들 사이의 유일한 연결 고리는 레지스트리가 된다.
 애플리케이션은 특정 기능이나 테스트를 목적으로 하는 구조화된 서비스 로케이터를 여러 개 사용할 수 있다. 서비스 로케이터는 프로세스당 하나의 단일 정적 클래스를 강제하지 않는다.
 잘 구조화된 컴포넌트/서비스 설계를 갖춘 애플리케이션의 경우 의존성 주입보다 서비스 로케이터를 사용하는 솔루션이 더 단순할 수 있다. 이러한 경우 단점은 오히려 장점으로 간주될 수 있다(예: 모든 클래스에 다양한 의존성을 제공하고 의존성 구성을 유지 관리할 필요가 없음).
 서비스 위치 확인 프로세스는 특정 비즈니스 사례를 나타낼 수 있는 호출 범위/컨텍스트에 민감하게 만들 수 있다. 일반적으로 생성자 매개변수 전달을 통해 객체에 의존성을 공급하는 고정된 DI에 의존하는 대신, 필요에 따라 비즈니스 컨텍스트 내에서 서비스 위치 호출을 수행할 수 있다. 예를 들어, 서비스 로케이터 호출을 통해 얻은 "IShippingStrategy" 인스턴스를 호출하면서 무엇이 어디서 어디로 배송되는지를 명시하는 "ShippingContext"를 서비스 로케이터에 매개변수로 전달하여 서비스 로케이터가 최상의 사례(예: 패턴 매치 점수 사용)를 일치시키도록 할 수 있다. 이는 실행 시간에 동적으로 위치한 최적의 매칭 전략의 점수화를 통해 복잡한 의사결정이 이루어질 수 있는 복잡한 비즈니스 애플리케이션 아키텍처(예: 의료 스코어링 시스템, 라우팅)를 크게 단순화한다.

 단점 
 레지스트리는 클래스의 의존성을 숨기므로, 의존성이 누락되었을 때 (생성자 주입을 사용할 때와 달리) 컴파일 타임 에러 대신 런타임 에러를 유발한다.
 모든 테스트가 테스트 대상 클래스의 가짜 의존성을 설정하기 위해 동일한 전역 서비스 로케이터 클래스와 상호작용해야 하므로, 레지스트리는 코드를 테스트하기 어렵게 만든다.

 같이 보기 
 의존성 주입
 의존관계 역전 원칙
 JNDI

 각주 

 외부 링크 
 샘플 코드

분류:소프트웨어 디자인 패턴
분류:아키텍처 패턴