[디자인 패턴] 퍼사드 패턴

퍼사드 패턴 (Facade Pattern)

 

https://refactoring.guru/ko/design-patterns/facade

 

 

퍼사드 패턴은 라이브러리에 대한, 프레임워크에 대한 또는 다른 클래스들의 복잡한 집합에 대한 단순화된 인터페이스를 제공하는 구조적 디자인 패턴입니다.

 

Facade는 "건물의 정면"을 의미하는 단어로 어떤 소프트웨어의 다른 커다란 코드 부분에 대하여 간략화된 인터페이스를 제공해주는 디자인 패턴을 한다. 퍼사드 객체는 복잡한 소프트웨어 바깥쪽의 코드가 라이브러리의 안쪽 코드에 의존하는 일을 감소시켜 주고, 복잡한 소프트웨어를 사용 할 수 있게 간단한 인터페이스를 제공해준다.

 

 

https://velog.io/@newtownboy/%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-%ED%8D%BC%EC%82%AC%EB%93%9C%ED%8C%A8%ED%84%B4Pacade-Pattern

 

장점

: 복잡한 하위 시스템에서 코드를 별도로 분리하여 특정 기능을 편리하게 사용가능하다.

: 하나의 퍼사드를 관련 없는 기능들로 오염되는 것을 방지할 수 있어 해당 시스템에 대한 응집도가 높다. (캡슐화)

 

단점

: 하위 시스템과 직접 작업하는 것과 비교하면 퍼사드는 제한된 기능성을 제공한다.

 

 

→ 복잡한 하위 시스템에 대한 제한적이지만 간단한 인터페이스가 필요할 때 사용한다.

→ 하위 시스템을 계층들로 구성하려는 경우 사용한다.

 

 

 

프로젝트에 적용하기

service 객체가 여러 domain의 repository를 의존해야하는 경우들이 있다. 이때 너무 많은 의존을 가져간다면 해당 도메인의 service 객체는 응집성이 떨어질 뿐 아니라 스프링 빈의 순환 참조 에러가 발생할 수 있다.

이때 퍼사드 패턴을 적용하여, 각각의 도메인 service는 해당 도메인 repository에 대한 의존성 하나만 갖고 그러한 service들을 조합해주는 퍼사드 레이어를 생성할 수 있다. 이 경우 레이어는 깊어지겠지만 해당 기능에 대한 단위 테스트도 깔끔하게 진행할 수 있을 것이다.

 

 

@Service
@RequiredArgsConstructor
public class OrderFacadeService {

	private final OrderService orderService;

	private final StoreService storeService;

	private final UserService userService;

	private final ItemService itemService;

	private final OrderMapper orderMapper;

	private final PaymentService paymentService;
    
    
    .. // 생략
}

주문 로직을 처리하기 위해 사용되는 많은 도메인들..  OrderFacadeService를 구성한 덕분에 OrderService의 응집도를 높이고 순환 참자를 해결하였다. 

 

 

 

 

reference.

https://refactoring.guru/ko/design-patterns/facade

https://leeheefull.tistory.com/13

 

 

 

잘못된 정보가 있다면 댓글을 통해 알려주세요. 감사합니다.