톰 드마르코와 메이릴 페이지 존스는 응집도를 모듈 요소 간의 기능적인 연관으로 정의했다. 이번 챕터는 모듈이나 클래스의 변경을 야기하는 응집력에 대해 이야기하고 있다.
단일 책임 원칙(SRP)
단일 책임 원칙이란 한 클래스는 단 한 가지의 변경 이유만을 가져야 한다는 원칙이다. 챕터 6장의 볼링 게임의 예를 살펴보면 책임에 따라서 2개의 클래스로 분리한 것을 볼 수 있었다. 왜 각 책임을 별개의 클래스로 분리할까? 그것은 책임이 변경의 축이기 때문이다. 요구사항이 변경되면 자연스럽게 클래스 안에 책임이 변경된다. 이때, 한 클래스가 하나 이상의 책임을 맡는다면, 그 클래스는 변경할 하나 이상의 이유가 있는 것이다.
한 클래스가 하나 이상의 책임을 맡게 되면 그 책임들은 결합되게 되고, 한 책임에 대한 변경은 다름 책임을 충족시키는 클래스의 능력을 저하시킬 수도 있다. 이런 책임의 결합은 변경을 했을 때 예상치 못한 방식으로 잘못 동작하는 취약한 설계를 유발하게 된다.
책임이란 무엇인가?
SRP 맥락에서 책임을 '변경을 위한 이유'라고 정의하겠다. 한 클래스를 변경하기 위한 한 가지 이상의 이유를 생각할 수 있다면, 그 클래스는 한 가지 이상의 책임을 맡고 있는 것이다. 여기서 조금 주의해야할 점은 그 책임이 분리되어야하는가를 잘 판단해야한다는 것이다. 책임을 분리하지 않아서 그 책임들이 결합되게되고, 그로 인해서 결국 취약성, 경직성 등 설계의 악취가 나기 시작하면 그 책임은 분리해야한다. 하지만 앞에서 책임이 변경의 축이라고 말했는데, 변경의 축은 실제로 변경이 일어날 때 변경의 축인 것이다. 아무 증상도 없는데 무작정 SRP나 다른 원칙을 과도하게 적용하는 것은 오히려 불필요한 복잡성이라는 악취를 야기한다.
하지만 이런 것을 판단하기가 쉽지 않을 것이다. 이럴 때 우리에게 큰 도움을 주는 것이 테스트 주도 개발, TDD이다. TDD는 그 모듈의 사용자 입장에서 모듈을 먼저 바라볼 수 있기 때문에, 보통 설계에서 악취가 나기 한참 전에 책임이 분리되도록 만든다.
결론
SRP는 가장 간단한 원칙 중 하나임과 동시에 제대로 적용하기 가장 어려운 원칙이기도 하다. 그렇기에 TDD 방식을 사용하며 스스로 자신의 소프트웨어 설계에 대한 피드백을 받을 필요가 있을 것 같다. 이 글을 읽으면서 개인적으로 나는 너무 SRP에 집중하여 불필요한 복잡성이라는 악취를 눈치채지 못한 것 같다. 해당 부분을 고려하여 리팩토링을 실시해야겠다.
