인프런 커뮤니티 질문&답변
작성한 질문수
파사드 패턴에 대해 질문이 있습니다.
작성
·
113
0
안녕하세요 강의 잘 보고 있습니다.
파사드 패턴에 대해 질문이 있습니다.
얄코님이 올려주신 예시에선 다음과 같이 두 상황이 나온다고 이해했습니다.
다양한 서브 시스템을 파사드 클래스로 조합해 하나의 새로운 로직을 만듦.
여러 서브 시스템을 생성시키고 세부 로직을 파사드 클래스에 위임.
1번의 경우는 일종의 추상화로 이해하였으며, 2번의 경우 서브 시스템에 대한 의존성 주입을 파사드 클래스에 위임 및 세부적인 로직을 캡슐화하는데 의의를 두었다고 이해했습니다.
만약 의존성 주입은 자동으로 이루어지는 3-layer 아키텍쳐에서 파사드 패턴을 도입할 경우 이미 service 레이어에서 내부 로직에 대해 캡슐화가 되었으므로
다양한 서브시스템을 파사드 클래스로 조합하는 것(ex. 1번)에만 집중하면 될까요?
답변 3
0
세부적인 상황까지 말씀드리도록 하겠습니다.
현재 저는 제가 참여하고 있는 사이드 프로젝트에서 리팩토링을 담당하고 있습니다.
하나의 서비스 클래스에 다양한 책임과 역할이 혼합되어 있는 것을 발견하고 이를 역할에 맞게끔 분리하였습니다.
그러나 리팩토링 이후에는 하나의 컨트롤러 클래스의 메서드에서 너무 많은 서비스 클래스에 의존하고 있는 문제를 발견하였습니다.
이에 대한 해결책으로 저는 아래의 방법을 도입했습니다.
파사드 패턴 도입으로 의존하고 있는 서비스 클래스의 수를 줄인다.
컨트롤러를 더 잘게 쪼갠다.
다만 리팩토링을 하는 다른 팀원의 경우 하나의 서비스 메서드를 단순히 호출하는 경우에도 파사드 클래스를 도입하여 결과적으로 하나의 거대한 파사드 클래스가 만들었습니다.
하나의 거대한 파사드 클래스 개인적으로는 무엇인가 잘못되었다는 느낌을 받았지만 파사드 패턴을 도입한 것이 이번이 처음이였으며 주변에 의견을 물어볼 곳도 마땅히 없었기에 넘어갔습니다.
다만 얄코님의 디자인 패턴 강의를 보며 조언을 구하고 싶은 마음에 위와 같이 질문을 남겼습니다.
저의 경우 다양한 서브 시스템을 파사드 클래스로 조합해 하나의 새로운 로직을 만듦 에 초점을 두어 파사드 패턴을 도입하였습니다. 같이 리팩토링을 진행한 팀원의 경우는 여러 서브 시스템을 생성시키고 세부 로직을 파사드 클래스에 위임 에 초점을 두어 진행하였습니다.
다만 사이드 프로젝트의 기술스택은 Spring을 사용중이고 의존성 주입이 자동으로 됩니다. 또한 파사드 패턴을 도입하고자 고민하고 있는 레이어는 서비스 레이어로 이미 로직이 추상화가 되어있기에 전자의 경우만 고려하면 될 것 같다는 생각이 드는데 이에 대한 얄코님의 의견이 궁금합니다.
0
안녕하세요, 이상민 님!
강의를 수강해주셔서 감사합니다.
기억해주서야 할 것이, 이러한 패턴들은 어디까지나 '수단'이라는 것입니다.
패턴을 적용하는 것이 목적이 되어서는 안 되고, 이 패턴을 적용함으로써 해당 프로그램이 전반적으로 나아질 것인가를 고민해야 해요. 이건 해당 프로그램을 짜는 사람이 가장 잘 판단할 수 있습니다. 코드 전반의 구조, 이후에 어떤 기능이 더해질지 등을 본인이 알기 때문이죠.
질문의 내용으로는, 파사드 패턴을 일단 도입하는 것에 목적을 두시는 것처럼 들립니다.
프로그램마다 설계와 디테일이 다양하고, 그것이 어떻게 사용될지에 따라 너무나 많은 변수가 있기 때문에
이들을 전반적으로 고려하여 패턴을 선택해서 적용해야 합니다. (아예 다른 설계가 필요할 수도 있구요.) 때문에 저도 이를 살펴보지 않는 이상은, 말씀주신 바만으로는 확답을 드리기 어려워요.
현재 아직 템플릿 메소드 패턴까지 수강하신 상태인데
좀 더 많은 패턴들을 살펴보신 뒤 어떤 패턴이 시스템에 맞는지 고민해보셔도 좋을 것 같습니다.
혹은 파사드 패턴을 적용해야 하는 특정 이유가 있는 것이라면, 상황을 좀 더 자세히 설명해주시면 살펴보고 답변을 드릴 수 있을 것 같습니다.
0
말씀주신 바를 토대로 제 생각을 말씀드리겠습니다. 다만, 주신 설명으로도 저는 어디까지나 피상적으로밖에 상황을 알지 못하며 제 답변은 추상적인 의견 정도에 그칠 것임을, 실질적인 해답은 이상민 님께서 해당 프로젝트의 전반적인 면을 감안하여 찾아야 함을 미리 말씀드립니다.
우선, 파사드 패턴의 목적은 복잡한 서브시스템들을 단순화하여 클라이언트가 서브시스템의 복잡성을 몰라도 되도록 하는 것입니다. 이건 클라이언트 코드의 복잡성을 줄이고 의존성을 관리하는데 도움되죠. 그러나 이것이 파사드를 "거대한 클래스"로 만들어서 전체 시스템의 복잡성을 감추는 방식으로 사용되면, 오히려 코드가 더 불투명해지고 유지보수가 어려워질 수 있습니다. 이 부분에서 고민을 느끼신 것 같고 합당한 우려인 것 같습니다. 이런 경우 파사드 패턴이 실질적으로 서브 시스템을 단순화하는 대신, 오히려 또 다른 복잡성을 만들어내는 상황이 될 수 있습니다. 파사드를 '모든 것을 처리하는 클래스'로 만들어 버리면, 의존성 주입이 자동으로 이루어지는 Spring 환경에서도 오히려 코드의 가독성이 떨어질 수 있습니다.
이상민 님께서 언급한 것처럼, 서비스 레이어에서 이미 추상화가 이루어졌다면 불필요한 중간 레이어를 추가하는 것은 오히려 코드의 복잡성을 증가시키는 방향일 수 있습니다. 이 경우, 파사드를 적용하는 것보다 각 컨트롤러가 필요한 서비스에 직접 의존하고, 각 서비스가 자신에게 적합한 책임을 유지하는 것이 더 적합할 수 있습니다.
궁금한 점은, 이 이슈에 관해서 해당 팀원과 깊이 있는 논의를 거칠 수 있는 상황인가입니다. 프로젝트 진행에서 중요한 점은 뭔가 이상하다고 느낄 때 지속적으로 팀원과 소통을 거쳐 더 나은 해결방안을 찾아내는 것인데, 주신 글의 내용으로는 이것이 어려운 상황이 아닌가 생각이 듭니다.
여튼 말씀주신 내용을 토대로는, 하나의 거대한 파사드가 아닌 적절한 규모로 파사드를 운용하는 이상민 님의 방식이 좋다고 생각됩니다.