이번 장에서는 TDD를 하기 위해서 필요한 객체지향의 개념에 대해서 살펴본다. 객체지향이라고 해서 클래스가 무엇인지 인터페이스가 무엇인지를 다룬다기 보다는 이러한 개념을 가지고는 있지만 이것을 제대로 활용하기 위한 내용이 될 것이다. TDD를 도입하면서 가지게 되는 이점 중 하나가 바로 객체지향적인 코드를 보장해 주는 것이라고 언급했었다. 물론, TDD를 하면서 설계에 많은 고민을 가지게 됨으로써 보다 객체지향적인 코드를 설계하고 배워 나가는 것도 있다. 하지만이번 장에서는 그러한 시행착오를 없애기 위한내용으로 TDD를 위한 필수적인 객체지향 패턴들과 규칙들을 살펴보도록 하겠다.
솔리드 디자인 원칙
솔리드(SOLID)는 다섯개의 객체지향 패턴으로 구성된 디자인 컨셉이다. 솔리드의 의미는 실제 그 각각의 디자인 규칙들의 첫번째 이니셜들을 묶어서 붙여진 것이다. 그럼 각각의 규칙들의 이름을 알아 보도록 하자.
하나의 기능 - Single responsibility
개방과 폐쇄 - Open-closed
리스코브 대입 - Liskov substitution
인터페이스의 분리 - Interface segregation
의존성의 반전 - Dependency inversion
위의 다섯가지 규칙은 필자가 영국에서 개발자로 활동하면서 가장 많이 공부한 디자인 패턴들이다. 한국과 다르게 영국은 디자인 패턴과 컨셉들을 굉장히 중요하게 여겼다. 이유는 솔리드 디자인 원칙에 맞추어 코드를 작성하면 보다 구조적이고 높은 퀄리티의 소스코드를 지향하기 때문이다.
TDD에서도 이 디자인 컨셉을 적용할 경우에 실제 작성된 코드를 리팩토링하는 수고를 덜 수 있다. 이번 장에서는 대부분의 내용을 이 디자인 패턴을 소개하고 적용해보는 것으로 채워갈 것이다.
지금까지 수많은 객체지향적인 디자인 패턴들이 소개되어 왔고 또한 많은 디자인 패턴 도서들에서도 수많은 디자인 패턴들을 소개하고 있다. 필자 또한 패턴 이름을 전혀 모르고 코드를 작성했지만 세월을 돌아서 패턴을 공부하다 보면 이미 이용해왔을 뿐 이름을 몰랐을 뿐이었던 적도 많이 있다.
이런 수많은 디자인 패턴들 속에서의 문제는 어떤 환경에서 어떻게 도입해야 될지에 대해서는 항상 개발자들이 풀어야 하는 숙제일 뿐만 아니라 상황에 따라서 그 디자인 패턴들이 단점이 더 크게 작용할 수 있기도 하다. 예를 들어 솔리드 디자인 원칙 중 하나의 규칙에서는 컴포지트 패턴을 쓰는 것보다는 스트레티지 패턴을 쓰는 것을 권고하고 있다.
솔리드 디자인 컨셉에서 소개하고 있는 다섯가지 원칙들은 명확하게 객체들을 어떻게 정의하고 또한 구분해서 개발해야 되는지에 대한 규칙을 보다 자세히 설명하고 있다. 그럼 첫번째 규칙부터 살펴보도록 하자.