의존성 주입의 파라미터 개수 많으면 안돼?

파라미터 개수는 3개 이하로 유지해야 한다는 것을 봤다.

그러다가 의존성 주입을 하다 보니 생성자에 파라미터 개수가 많아지는 것을 보고

이것이 잘못된 설계인가? 고쳐야 하나?라는 고민이 들었다.

"근데 왜 파라미터 개수는 3개 이하로 하라는 거지?" 궁금증이 생겼다.

 

그렇다면 파라미터 개수는 왜 3개 이하로 유지해야 하는지부터 짚고 넘어가자.

우선 파라미터 개수를 최대한 적게 유지해야 한다는 것은 그 메서드를 사용하는 클라이언트 측에서

실수를 줄이기 위한 것이었다.

 

만약 파라미터로 (년도, 월, 일, 시, 분)을 int로 받는 메서드가 있을 때 클라이언트 측에서

실수로 월을 일과 바꿔 넣거나 시와 분을 바꿔 넣어도 컴파일 단계에서 아무런 문제가 발생하지 않는다.

이런 실수가 먼 미래에 발견된다면 실수를 찾기도, 유지보수하기도 힘들 것이다.

그렇기 때문에 파라미터 개수는 최대한 적으면 적을수록 좋다.

 

자 그렇다면 의존성 주입에서 파라미터 값으로 여러 객체들을 받는 것은 연관이 있을까?

찾아본 결과 의존성 주입은 문제 되지 않는다.

 

보통 내가 만든 특정 클래스를 받을 것이기 때문에 해당 클래스 객체가 아니라면

주입받을 수 없어서 제약이 생긴다.

이 제약으로 인해 개발자는 int형으로 받던 위의 상황과 같은 실수를 없앨 수 있다.

 

파라미터의 개수를 3개 이하로 유지하라는 것은 예상 못할 문제를 막기 위한 것이다.

그러니 의존성 주입에서는 이미 클래스로 제약을 걸어서 예상할 수 있기 때문에 고민할 필요 없다.

 

물론 파라미터로 많은 객체들을 알고 있다면 설계측면에서 올바른가? 고민했던 것도

문제가 되지 않는다고 결론 내렸다.

객체를 주입받아 사용하려는 것은 내가 가진 책임을 해내기 위해 협력하는 것이다.

그 객체에게 메시지를 보내고 부탁하는 것이지 내 책임이 늘어나는 것이 아니다.

 

많은 객체를 알고 있으면 그것도 책임으로 보는가 고민했는데 내 책임을 하기 위해 협력한다고 생각하자.