정의
A module should have one, and only one, reason to change.
하나의 모듈은 단 하나의 변경 사유를 가져야 하는 것이 single responsibility principle(이하 SRP)의 정의입니다.
Reason to change
소프트웨어가는 user와 stakeholder에 의해 변하게 됩니다. 즉, user와 stakeholder가 변경 사유가 되며 Uncle Bob은 다수의 user와 stakeholder를 하나의 actor라는 그룹으로 묶어서 다음과 같이 SRP를 재정의 하였습니다.
A module should be responsible to one, and only one, actor.
SRP를 어길시 발생할 수 있는 일들
Accidental Duplication
하나의 클래스에 여러 actor에 responsible할 경우 actor간 서로 예기치 않은 coupling이 발생할 수 있습니다.
위의 그림에서 Employee 클래스는 총 3개의 actor에 대해 responsible한 것을 볼 수 있습니다.
- calculatePay()는 CFO의 팀에서 사용
- reportHours()는 COO의 팀에서 사용
- save()는 CTO의 팀 DBA가 사용
클래스의 3개의 method 중 calculatePay()와 reportHours()는 둘 다 시간에 관련되어 있어서 아래와 같이 시간을 계산하는 regularHours()를 호출하는 경우가 발생할 수 있습니다.
이런 경우 regularHours()의 변경이 이루어질 경우 calculatePay() 혹은 reportHours()의 동작이 의도치 않게 변경될 수 있습니다.
예를 들어 CFO가 calculatePay()의 변경을 요구하여 regularHours()의 동작까지 수정해야 할 경우 COO의 팀에서 사용하는 reportHours()의 동작까지 변경될 수 있습니다.
Merges
여러 actor에 responsible한 클래스는 merge가 자주 발생할 수 있습니다.
둘 이상의 actor가 클래스에 대해 수정을 하게 될 경우 해당 클래스에 대해 충돌이 발생하게 되면 수정사항에 대해 merge를 해야합니다.
요즘은 git같은 tool이 merge를 자동으로 처리해주는 경우도 있지만 모든 merge에 대해 처리할 수는 없으므로 manual merge가 일어날 수 있습니다. Manual merge는 사람이 하는 일이므로 실수가 발생할 여지가 있으며 이로인해 잘못 merge를 하게 되면 일부 변경사항이 적용이 되지 않아 클래스의 동작이 올바르지 않게 됩니다.
예를 들어 DBA가 Employee 클래스의 schema를 변경하기 위해 save()를 수정하고, COO팀이 hour report format을 변경하기 위해 reporHours()을 수정하게 되면 충돌이 발생할 수 있고 이는 manual merge로 이어질 수 있습니다.
Reference
[1] Robert Martin, Agile software development: principles, patterns, and practices (n.p.: Pearson, 2013), 127-134.
[2] Robert Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design (n.p.: Prentice Hall, 2017), 61-67.
