극락이들의 CleanCode 가이드 문서입니다.
⇒ 궁금한 점이 있으면 극락(
)에게 질문해주세요!
)에게 질문해주세요!하나의 프로그램을 만들때 복잡도를 줄이기 위해서 서브 시스템으로 나누어 구현합니다. 단일 책인 원칙 SRP를 지키기 위해서 서브 시스템 클래스는 각각의 역할과 책임을 가집니다!
그런데, 프로그램을 만들다보면 서브 시스템 끼리 종속성이 생길 수 있습니다.
예를 들어 Post라는 도메인에서 게시물을 생성하는데, Member에 대한 정보가 필요하면, Post에서 Member를 끌어다가 사용하는 일처럼요!!
혹은 종속성이 발생하는 문제가 아니라, 클라이언트가 어떤 큰~ 규모의 비즈니스 로직을 원할 때 다수의 서브시스템과 일대다로 통신하게 된다면 복잡한 커뮤니케이션이 발생하게 됩니다!!
이럴때 유용하게 쓰일 수 있는 방식이 퍼사드 패턴(퍼사드 레이어)입니다!
Facade Pattern
어떤 서브시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공합니다. 퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브시스템을 더 쉽게 사용할 수 있습니다.
복잡한 처리가 필요한 기능이 있다면, 기능 자체는 서브시스템을 통해 진행하고, 파사드를 통해 묶어주면서 외부에서 간단한 인터페이스만을 노출할 수 있는 장점이 있습니다!
퍼사드 레이어가 더 높은 추상화를 위해서 사용하는 것이냐?→ 결론은 아닙니다. 퍼사드 레이어는 서브 시스템을 사용하는데 더 쉽게 하기 위해서 제공하는 인터페이스입니다. 그렇기 때문에 더 높은 추상화를 위하는 것이 아니라 클라이언트가 더 쉽게 코드를 운용할 수 있도록 제공하는 것이 목적입니다!
client는 특정 기능(CPU, MEMORY, HardDrive) 등을 사용하기 위해 Computer를 이용하고 있습니다.
computer는 퍼사드로서 cpu, memory, hardDrive를 이용합니다.
cpu, memory, harddrive를 바로 client에서 사용할 수 있지만, Computer라는 퍼사드를 통해서 CPU, Memory, HardDrvie 등 복잡한 서브 시스템을 직접 참조하지 않고 사용할 수 있습니다.
한번 묶어줌으로써, client는 더 쉽게 서브 시스템을 이용할 수 있게 됩니다.
우리가 자주 사용하는 배달의 민족, 이츠도 어떻게 보면 퍼사드이겠네요!
스프링에서 파사드 레이어를 도입하지 않았을 때 발생하는 문제입니다.
클라이언트는 하나의 비즈니스 로직을 수행하기 위해서 필요한 모든 Service와 연결되게 됩니다. 그만큼 복잡도가 올라가고 클라이언트가 가지는 비즈니스 로직도 무거워집니다
위의 상황은 스프링에서 파사드 레이어를 사용했을 때입니다.
클라이언트는 InventoryService, PaymentService, ShippingService 등이 필요합니;다. 그런데 다수의 Service로직을 직접 참조하면서 진행할 경우 Client가 가지는 비즈니스 로직은 방대해질 겁니다.!
이경우에느 Facade라는 calss를 통해 한번 묶어줌으로서, Client는 Facade만을 바라보게 되고, 결과적으로 Client가 가지는 비즈니스 로직은 줄어들게 됩니다.