OOP와 다형성, 의존 역전

다형성

 

객체지향에서 말하는 다형성이란 무엇인가? 위키피디아에서는 "프로그램 언어 각 요소들(상수, 변수, 식, 객체, 메소드 등)이 다양한 자료형(type)에 속하는 것이 허가되는 성질"이라고 말하고 있으며, 오버라이딩으로 대표되는 런타임 다형성과 오버로딩으로 대표되는 컴파일 다형성을 자연스럽게 떠올리게 될 것이다.

 

 

의존 역전

 

 하지만 사실 다형성의 진가는 DIP와 플러그인 아키텍쳐의 기반이 된다는 데에 있다. '클린 아키텍쳐'라는 책에서는 '객체지향의 다형성이 제어의 흐름을 간접적으로 전환하는 규칙을 부과한다'라고 말하고 있다. 다형성이라는 개념이 사용되기 전 소프트웨어는 어떤 모습이었을까? 모든 프로그램들은 main함수가 고수준 함수를 호출하고, 고수준 함수가 저수준 함수를 호출하는 형태로 되어 있었을 것이라고 예상할 수 있다. 

 

제어흐름과 의존성의 방향이 일치한다 - 출처: clean architecture

 

모든 호출함수는 피호출 함수의 이름을 명시해야 하고, 결국 프로그램의 제어 흐름은 시스템의 동작에 따라 결정되며, 소스코드의 의존성은 제어흐름에 따라서 결정되는 일방적인 흐름이 만들어졌을 것이다.

 

 

 하지만 다형성을 적용하면 이러한 일방적인 흐름에 변화가 생긴다.

 

제어흐름과 의존성의 방향이 일치하지 않는다

 

 

 위와 같이 간단한 예를 보자. 고수준 모듈인 M1은 저수준 모듈 M2의 f1() 메소드를 호출한다. 다시말해 고수준 모듈인 M1이 저수준 모듈인 M2를 호출하는 제어 흐름을 가진다. 하지만 소스코드상으로 M1은 M2에 대해 알지 못하며, 단순히 인터페이스 I1의 추상 메소드 f1()을 호출했을 뿐이다. 여기서 모듈 M2가 인터페이스 I1에 의존성(상속)을 가졌지만, 제어 흐름은 인터페이스 I1를 통해서 모듈 M2로 들어가는 것을 확인할 수 있다. 이는 제어의 흐름이 의존성과 정반대라는 것을 의미한다.

 

제어의 흐름은 호출하는 모듈에서 구현체가 존재하는 모듈로 연결되지만, 호출하는 모듈의 의존성은 인터페이스가 존재하는 모듈로, 구현체가 존재하는 모듈의 의존성은 인터페이스가 존재하는 모듈로 연결된다. 결국 OOP의 다형성은 의존성을 역전시킬 수 있게 만들며, DIP의 기반이 된다고 말할 수 있을 것이다.

 

 

결론

 그래서 이러한 현상이 어떤 특별한 의미를 가질까?

 

 소스 코드의 의존성이 제어의 흐름과 반대가 될 수 있다는 것은, 다시 말해 아키텍쳐 전체에 제어와 상관없이 의존성의 방향을 결정할 수 있게 된다는 것을 의미한다. 이제 업무 규칙이 데이터베이스에 의존적이지 않고, 데이터베이스가 업무 규칙에 의존할 수 있게 되었다. 다시 말하면 이제 업무 규칙을 데이터베이스와 같은 다른 컴포넌트와 독립적으로 결정할 수 있다! 데이터베이스 단위의 변경사항은 업무 규칙에 전혀 영향을 끼치지 않으며, 컴포넌트에 변화가 일어나면 각 컴포넌트만 따로 배포함으로서 배포 독립성(Independent Deployability)을 만들어 낸다. 이것이 결국 팀 단위로 서로를 신경쓰지 않고 모듈을 독립적으로 개발하는 개발 독립성(Independent Developability)의 기반이 된다.

 

다시 돌아가서, 그렇다면 객체지향과 객체지향 프로그래밍의 핵심은 무엇인가? 객체지향 프로그래밍이란 “다형성을 이용하여 전체 시스템의 모든 소스코드 의존성에 대한 절대적인 제어 권한을 획득하는 능력”이라고도 할 수 있다. 객체지향을 통해 플러그인 아키텍처를 구성하고, 모듈간의 독립성을 보장할 수 있게 된 것이다.