서비스 로케이터 패턴
Service locator pattern |
 |
서비스 로케이터 패턴은 강력한 추상화 레이어를 사용하여 서비스를 취득하기 위한 프로세스를 캡슐화하기 위해 소프트웨어 개발에 사용되는 설계 패턴입니다.이 패턴은 "service locator"로 알려진 중앙 레지스트리를 사용합니다. 이 레지스트리는 요청에 따라 특정 [1]작업을 수행하는 데 필요한 정보를 반환합니다.이 패턴의 지지자들은 이 접근방식을 통해 전체 애플리케이션 설계의 시작 부분에서 모든 종속성이 깔끔하게 나열되는 컴포넌트 기반 애플리케이션을 단순화하고 결과적으로 기존의 종속성 주입을 보다 복잡한 객체 연결 방법으로 만들 수 있다고 말합니다.이 패턴을 비판하는 사람들은 이것이 의존성을 가리고 소프트웨어를 [2][better source needed]테스트하기 어렵게 만드는 안티 패턴이라고 주장한다.
이점
- "service locator"는 단순한 런타임 링커 역할을 할 수 있습니다.이것에 의해, 애플리케이션을 재컴파일 하지 않고, 경우에 따라서는 재기동할 필요도 없이, 런타임에 코드를 추가할 수 있습니다.
- 응용 프로그램은 서비스 로케이터에서 항목을 선택적으로 추가하고 제거함으로써 런타임에 자체 최적화할 수 있습니다.예를 들어 어플리케이션은 디폴트보다 JPG 이미지를 읽기 위한 더 좋은 라이브러리를 가지고 있음을 검출하고 그에 따라 레지스트리를 변경할 수 있다.
- 라이브러리 또는 애플리케이션의 큰 부분은 완전히 분리될 수 있습니다.이들 사이의 유일한 링크가 레지스트리가 됩니다.
- 응용 프로그램은 특정 기능/테스트용으로 설계된 여러 구조화된 서비스 로케이터를 사용할 수 있습니다.서비스 로케이터는 프로세스당1개의 스태틱클래스를 필수로 하지 않습니다.
- 컴포넌트/서비스 설계가 잘 되어 있는 애플리케이션에서는 서비스 locator(의존성 주입에 비해)를 사용하면 솔루션이 더 단순해질 수 있습니다.이러한 경우 단점은 실제로 장점으로 간주될 수 있습니다(예를 들어 모든 클래스에 다양한 종속성을 공급하고 종속성 구성을 유지할 필요가 없습니다).
단점들
- 레지스트리는 클래스의 종속성을 숨기므로 종속성이 없는 경우 컴파일 시간 오류 대신 런타임 오류가 발생합니다(의존성 주입 사용과 유사).그러나 각 라이브러리는 컴파일되어 있기 때문에 구체적인 클래스가 발견되지 않아 오류가 발생할 수 있습니다.이것은 서비스 로케이터의 문제라기보다는 전개에 관한 문제입니다.
- 모든 테스트는 테스트 대상 클래스의 가짜 종속성을 설정하기 위해 동일한 글로벌서비스 로케이터 클래스와 상호 작용해야 하므로 레지스트리는 코드를 테스트하기 어렵게 만듭니다.단, 이는 단일 서비스 로케이터 인터페이스를 응용 프로그램클래스에 주입함으로써 쉽게 극복할 수 있습니다.시뮬레이터는 서비스 로케이터에 의해 제공되는 각 인터페이스를 시뮬레이션하기 위해 구현될 수 있으므로 실제 구현과 시뮬레이터를 쉽게 바꿀 수 있습니다.
「 」를 참조해 주세요.
레퍼런스
- ^ "Inversion of Control Containers and the Dependency Injection pattern".
- ^ Seemann, Mark. "Service Locator is an Anti-Pattern". blog.ploeh.dk. Retrieved 2017-06-01.
외부 링크
