Service Locator 패턴이란 ? #23
Comments
Service Locator 패턴과 DI들어가며,Service Locator과 Dependency Injection (DI) 패턴은 객체 지향 프로그래밍에서 객체의 의존성을 관리하기 위한 이 중, Service Locator 패턴은 조금만 검색해도 안티 패턴이냐에 대한 의문을 갖는 글들이 많이 보인다. Service Locator패턴은 몇 가지 이유들로 비판받기도 하지만, 특정 상황에서는 아주 유용하게 쓰이기도 하는 패턴이다. 그러면, Service Locator패턴과 DI 패턴에 대해 어떤 차이가 있는 지 알아보자. 의존성 주입
위와 같이 종속성이 있는 클래스들에서, new로 객체간의 종속성을 연결한다면 어떻게 될까?
클래스가 자체적으로 종속성을 생성하거나 초기화 하는 경우, 그 클래스는 원래의 업무(1)와 종속성 관리(2)의 또한, 특정 종속성이 구체적인 구현에 의존하게 된다면, 그 종속성을 변경하거나 대체하기 어려워지고, 이를 해결하기 위해 사용하는 패턴이 Service Locator 패턴과, DI 패턴인 것이다. Service LocatorService Locator 패턴은 서비스를 사용하는 클라이언트와 서비스를 제공하는 쉽게 말해, 객체의 의존성을 중앙저장소(Service Locator)에 저장해 놓고, 필요할 때마다 찾아서 쓰는 패턴이라고 생각하면 쉽다. public interface MessageService {
void sendMessage(String message);
}
public class EmailService implements MessageService {
public void sendMessage(String message) {
System.out.println("Email sent: " + message);
}
}
public class ServiceLocator { // 중앙 관리 저장소
private static Map<String, MessageService> services = new HashMap<>(); // key : value로 관리
public static void registerService(String name, MessageService service) {
services.put(name, service);
}
public static MessageService getService(String name) {
return services.get(name);
}
}
public class Notification {
public void notify(String message) {
MessageService service = ServiceLocator.getService("emailService"); // 의존성 가져오기
service.sendMessage(message);
}
}public class Application {
public static void main(String[] args) {
ServiceLocator.registerService("emailService", new EmailService());
Notification notification = new Notification();
notification.notify("홍박사님을 아세요?");
}
}이렇게 Notification 클래스는 ServiceLocator를 사용하여 필요한 서비스를 검색하고 있다.
장점:
단점:
문제점 :
Service Locator는 패턴은 일반적으로 서비스 요청을 런타임에 처리하기 때문에,
클라이언트가 필요로 하는 서비스만 찾기 위해 서비스 로케이터 인터페이스를 사용하면,
결론적으로, Service Locator 패턴은 특정 상황에서 서비스의 결합도를 줄이는 데 Dependency Injection(DI)Dependency Injection(DI) = 의존성 주입 public interface MessageService {
void sendMessage(String message);
}
public class EmailService implements MessageService {
public void sendMessage(String message) {
// send email
System.out.println("Email sent: " + message);
}
}
public class Notification {
private final MessageService service;
public Notification(MessageService service) {
this.service = service;
}
public void notify(String message) {
service.sendMessage(message);
}
}public class Application {
public static void main(String[] args) {
MessageService emailService = new EmailService();
Notification notification = new Notification(emailService);
notification.notify("Hello via Email!");
}
}여기서는 Notification 클래스가 MessageService의 특정 구현에 의존하지 않는다.
DI는 Service Locator에서의 문제를 어느정도 해결은 하지만, 종속성을 구성하고 생성하는 전용 클래스가 여전히 장점:
단점:
ref. |
👍 문제
p.425 ~ 426에서는 애플리케이션 점검 시 확인해야 할 패턴 및 아키텍처에 관해 얘기 하고 있습니다.이 중 Service Locator 패턴에 대해서 잘 알고 있으면 여러모로 도움이 되지 않을까 생각이 들었습니다.
잠깐 검색해보니 DI (#2)와 함께 언급되던데 , 부담이 되지 않는다면 연관해서 같이 정리해봐도 좋지 않을까 합니다!
이전에 디자인 패턴 찾아보면서 못 본 패턴이기도 하고, 마침 또 DI와 함께 언급되길래
이제 스프링을 (처음) 배우는 지금 시즌에 다 같이 정리해보면 좋을 것 같아서 선정했습니다.
📺 관련 챕터 및 레퍼런스
Story24. 애플리케이션에서 점검해야 할 대상들
🐳 비고
(only 희망사항) 가능하다면 실제 코드에서 패턴을 확인해볼 수 있으면 좋겠습니다 !
The text was updated successfully, but these errors were encountered: