[SOLID 원칙] 1. Single Responsibility Principle 단일 책임 원칙

OOP에서 SOLID와 같은 원칙은 왜 필요할까?

원칙이 필요한 이유는 바록 나쁜 디자인을 예방하거나 고치기 위함이다. 

그러면 나쁜 디자인이란 어떤것일까? 여러가지가 있겠지만 우선 아래와 같은 항목들로 정리해볼 수 있다.

 

유연하게 변화하지 못하는 경직성(Rigidity), 코드를 수정할 때 다른 코드까지 영향을 주는 취약성(Fragility), 모듈간 커플링이 높아 재사용이 어려운 부동성(Immobility), 나쁜 코드가 쉽게 추가될 수 있는 점착성(Viscosity), 불필요한 복잡성(Needless Complexity), 불필요한 반복(Needless Repetition), 불투명성등이 있겠다.

 

따라서 위와 같은 문제를 예방하거나 고치기 위해서는 개발 원칙을 준수하며 설계를 하는게 바람직하다.

 

그 첫 번째로

 

Single Responsibility Principle 단일 책임 원칙

정의 : 하나의 클래스는 단 하나의 책임을 가져야한다. 클래스의 책임이 여러개면 여러 책임 중 하나가 변경 될 때마다 해당 클래스의 수정이 동반된다.

 

정의는 매우 간단하지만 하나의 책임의 범위가 모호한 부분이 있다. 처음부터 단일 책임 원칙을 지키는 클래스를 만드는게 가장 좋겠지만,

이미 작성된 클래스의 책임이 여러개라고 생각되면 리팩토링을 통해 책임의 갯수만큼 클래스를 나누는 것도 좋은 방법이다.

 

 

 

단일 책임 원칙을 위반한 예

예를 들어 아래와 같이 디자인 했다고 가정해보자. 아래 디자인의 문제점은 Employee가 해야하는 책임 외에도 Email로 정렬 하기 위한 Comparable이라는 책임까지 가지고 있다. 만약 Employee의 Name을 기준으로 정렬해야 하는 추가 사항이 발생할 경우 Employee클래스가 수정이 발생하고 그 수정에 따라 HRManager까지 전파(propagation)될 수 있는 문제가 있다.

 

따라서 위의 문제를 해결하기 위해 단일 책임 원칙을 적용해서 아래와 같이 책임을 나누어 디자인한다.

책임을 나누어 디자인하면 Name으로 정렬하는 기능(SortByEmployeeName)이 추가되어도 HRManager 클래스는 수정이 필요없다.

 

단일 책임 원칙에 의해 모든 책임을 하나의 클래스로 잘게 나누는게 꼭 좋은건 아니다. 시스템의 변동이 거의 없는 경우에는 하나의 클래스에 둘이상의 책임이 있어도 괜찮은 경우가 있다. 이러한 경우에는 오히려 책임을 나누게 되면 클래스의 숫자가 많아저 코드의 복잡성이 올라가는 단점이 생기게 된다.

따라서 상황에 맞게 단일 책임 원칙을 적용하면 좋을것 같다.