인프런 커뮤니티 질문&답변

세부적인 상황까지 말씀드리도록 하겠습니다.

현재 저는 제가 참여하고 있는 사이드 프로젝트에서 리팩토링을 담당하고 있습니다.

하나의 서비스 클래스에 다양한 책임과 역할이 혼합되어 있는 것을 발견하고 이를 역할에 맞게끔 분리하였습니다.

그러나 리팩토링 이후에는 하나의 컨트롤러 클래스의 메서드에서 너무 많은 서비스 클래스에 의존하고 있는 문제를 발견하였습니다.

이에 대한 해결책으로 저는 아래의 방법을 도입했습니다.

1. 파사드 패턴 도입으로 의존하고 있는 서비스 클래스의 수를 줄인다.

2. 컨트롤러를 더 잘게 쪼갠다.

다만 리팩토링을 하는 다른 팀원의 경우 하나의 서비스 메서드를 단순히 호출하는 경우에도 파사드 클래스를 도입하여 결과적으로 하나의 거대한 파사드 클래스가 만들었습니다.

하나의 거대한 파사드 클래스 개인적으로는 무엇인가 잘못되었다는 느낌을 받았지만 파사드 패턴을 도입한 것이 이번이 처음이였으며 주변에 의견을 물어볼 곳도 마땅히 없었기에 넘어갔습니다.

다만 얄코님의 디자인 패턴 강의를 보며 조언을 구하고 싶은 마음에 위와 같이 질문을 남겼습니다.

저의 경우 다양한 서브 시스템을 파사드 클래스로 조합해 하나의 새로운 로직을 만듦 에 초점을 두어 파사드 패턴을 도입하였습니다. 같이 리팩토링을 진행한 팀원의 경우는 여러 서브 시스템을 생성시키고 세부 로직을 파사드 클래스에 위임 에 초점을 두어 진행하였습니다.

다만 사이드 프로젝트의 기술스택은 Spring을 사용중이고 의존성 주입이 자동으로 됩니다. 또한 파사드 패턴을 도입하고자 고민하고 있는 레이어는 서비스 레이어로 이미 로직이 추상화가 되어있기에 전자의 경우만 고려하면 될 것 같다는 생각이 드는데 이에 대한 얄코님의 의견이 궁금합니다.

안녕하세요, 이상민 님!
강의를 수강해주셔서 감사합니다.

기억해주서야 할 것이, 이러한 패턴들은 어디까지나 '수단'이라는 것입니다.

패턴을 적용하는 것이 목적이 되어서는 안 되고, 이 패턴을 적용함으로써 해당 프로그램이 전반적으로 나아질 것인가를 고민해야 해요. 이건 해당 프로그램을 짜는 사람이 가장 잘 판단할 수 있습니다. 코드 전반의 구조, 이후에 어떤 기능이 더해질지 등을 본인이 알기 때문이죠.

질문의 내용으로는, 파사드 패턴을 일단 도입하는 것에 목적을 두시는 것처럼 들립니다.

프로그램마다 설계와 디테일이 다양하고, 그것이 어떻게 사용될지에 따라 너무나 많은 변수가 있기 때문에
이들을 전반적으로 고려하여 패턴을 선택해서 적용해야 합니다. (아예 다른 설계가 필요할 수도 있구요.) 때문에 저도 이를 살펴보지 않는 이상은, 말씀주신 바만으로는 확답을 드리기 어려워요.

현재 아직 템플릿 메소드 패턴까지 수강하신 상태인데
좀 더 많은 패턴들을 살펴보신 뒤 어떤 패턴이 시스템에 맞는지 고민해보셔도 좋을 것 같습니다.

혹은 파사드 패턴을 적용해야 하는 특정 이유가 있는 것이라면, 상황을 좀 더 자세히 설명해주시면 살펴보고 답변을 드릴 수 있을 것 같습니다.

또한 컨트롤러 클래스는 파사드 클래스와 서비스 클래스에 동시에 의존하는 것은 좋은 설계인지도 궁금합니다.