의존성 주입이란 무엇인가?

학습했던 내용을 정리하기 위해 작성된 글이며 다소 부정확한 내용이 포함될 수 있음을 양해바랍니다.

이미 게시된 글이라도 복습하는 과정에서 내용이 보완 또는 수정될 수 있습니다.

 

 

객체지향 프로그래밍에서는 필연적으로 객체들 간의 협력을 요구한다. 각 객체들이 협력한다는 것은 서로 연결되어 있다는 것을 의미하고 이러한 특징을 의존성이라고 한다. 협력을 위해 의존은 필요하지만 과도한 의존은 코드의 유지보수를 어렵게 만들기도 한다. 객체들 간에 서로 주고 받는게 많아지다 보면 코드의 복잡도가 증가할 것이다. 하나의 기능을 수정하기 위해 수많은 코드를 수정해야만 하는 상황이 연출되기도 한다.

 

따라서 코드는 다양한 문맥에서 재사용할 수 있도록 작성하는 것이 바람직하다. 재사용하기에 용이하다는 것은 다른 요소와 유연하게 연결될 수 있고 수정하기에 용이하다는 것을 의미한다. 이를 위해서는 객체 간에 의존성이 과도하지 않아야 한다.

 

의존성이 너무 과도한 경우 이를 강한 결합, 반대의 경우 느슨한 결합이라고 표현하기도 한다. 의존성이 과하지 않다는 것은 느슨하게 결합된 상태를 의미한다.

 

느슨한 결합을 위해서는 추상화가 필요하다. 하나의 함수에 여러 로직이 얽혀 있다면 서로 의존관계를 갖는 것들끼리 묶어 추출하는 작업이 필요하다. 각각의 함수가 각자만의 책임을 갖고 역할을 수행하도록 해야 한다.

 

소프트웨어는 객체를 생성하고, 의존성을 연결하는 “시작” 단계와 시작 단계의 이후인 “실행”단계는 서로 분리되어야 한다.

 

엉클 밥이라는 사람이 했던 말이라고 하는데, 여러 곳에서 인용되는 것을 봤다. 객체의 생성과 사용을 분리하라는 말인데, 이는 관심사 분리의 컨셉과 유사하다. 함수의 의존성을 줄여주기 위해서, 다시 말해 객체와의 느스한 결합을 위해서는 함수를 좀 더 추상적으로 만들어 주어야 한다. 이는 변하는 부분과 변하지 않는 부분을 구분하여 관심사를 분리시켜 주는 것을 의미한다. 객체에 대한 생성과 사용을 분리시켜야 한다.

 

리액트 컴포넌트를 예로 들어보자.

 

하위 컴포넌트를 갖고 있는 상위 컴포넌트가 있다. 하위 컴포넌트의 객체에 클릭 이벤트가 발생하면 상위 컴포넌트에 이벤트 객체가 전달하도록 코드를 작성했다. 상위 컴포넌트는 전달받은 객체의 구조를 분해하여 필요한 값만 사용한다. 이런 상황에서 의존성 주입을 통해 코드를 개선시킬 수 있다. 하위 컴포넌트에서 이벤트 객체를 구조분해하여 상위 컴포넌트에 필요한 값만 전달해준다면 어떨까? 컴포넌트 간의 결합도가 더 느슨해질 것이다. 상위 컴포넌트는 필요한 값만 전달받아 '사용'만 하면된다. 외부에서 어떤 일이 발생하는지 알 필요가 없다.

 

결합이 엄청 강해보이는 편은 아니었지만, 만약 상위 컴포넌트에서 특정한 값을 사용하기 위해 이벤트 객체에 여러 가지 처리를 해줘야 하는 상황이었다면 이러한 작업이 더 절실한 상황이었을 것이다. 객체에 대한 의존도가 줄어들면 코드의 재사용성은 증가한다. 만약 어떤 함수가 특정 타입의 객체가 아닌 필요한 값만을 받아 작업을 처리할 수 있다면, 함수의 범용성이 크게 증가할 것이다.

 

이렇게 의존관계를 제거하고 외부에서 의존관계를 넣어주도록 하는 것을 의존성 주입(Dependency Injection)이라고 일컫는다. (라고 했지만...) 확실히 용어에서 주는 어려움이 있다. 의존성을 주입한다고 하니까 의존성이 더 강해질 것만 같고, 단어 자체가 주는 낯선 느낌이 한 몫하는 것 같다.

 

의존성 주입에는 다음과 같은 장점이 있다.

• Unit Test가 용이해진다.
• 코드의 재사용성을 높여준다.
• 객체 간의 의존성(종속성)을 줄이거나 제거할 수 있다.
• 객체 간의 결합도를 낮추면서 유연한 코드를 작성할 수 있다.

사실 아직 의존성에 대해서 충분히 이해하진 못했다. 복잡한 코드를 다뤄본 경험도 많지 않아 의존성 주입의 필요성도 충분히 느껴보진 못했다. 다만 배우는 입장에서 좋은 코딩 습관을 갖기 위해 코드 리뷰를 통해 접하게 된 개념을 정리해 보았다. 좋은 코드를 작성하기 위한 패러다임들이 모두 연결되어 있다는 느낌을 받는다.