이번 포스트에서는 SOLID 원칙의 첫 번째인 SRP 에 대해서 예시와 함께 다뤄보려고 한다.
SRP (Single Responsibility Principle)
SRP 는 Single Responsibility Principle 의 약어로, 단일 책임 원칙을 의미한다. SRP 의 개념은 다음과 같다.
There should never be more than one reason for a class to change.
클래스를 변경하는 이유는 단 한 가지여야 한다.
좀 더 풀어서 설명하면, 클래스는 하나의 책임만을 가져야한다는 원칙이다.
예를 들어 프론트 클라이언트 단에서 데이터를 처리할 때 데이터를 로드하는 클래스, 데이터를 보여주는 클래스, 그리고 데이터를 관리하는 클래스의 책임이 분리되어야 기능 변경시 코드 변경을 최소화할 수 있다.
그러나 Fig1 만 보면 만약 SRP 가 분리되지 않았을 때 어떤 불편함이 생기는지 알 수 없다.
SRP 위반 시 생기는 문제점
그럼 SRP 를 위반했을 때 어떤 문제점이 생길 수 있는지 예시를 통해 알아보자.
Fig1 에 설계된 DataViewer 클래스를 보면 클래스명을 보아 Data 를 보여주는 책임을 갖는 클래스로 보이나, 포함한 메서드들을 보면 다음을 포함하고 있다.
- display() : 데이터를 로드하고, 보여주는 함수
- loatHtml() : HTML 으로 작성된 소스를 로드하는 함수
- parseDataToGuiData() : HTML 으로부터 로드된 데이터를 시각적인 데이터로 변환해주는 함수
- updateGui() : 사용자에게 보여줄 데이터를 GuiData 타입 객체를 사용하여 시각적으로 업데이트 하는 함수
DataViewer 클래스는 Data 를 보여주어야 하는 클래스로 보이나, 실제로는 다음과 같은 역할들까지 하는 셈이다.
- HTML 데이터를 로드한다.
- 로드된 HTML 데이터를 GuiData 로 변환한다.
- GuiData 를 사용하여 화면에 보이는 데이터를 바꾼다.
그러나 다음과 같은 상황이 발생한다고 했을 때 어떻게 코드를 수정해야 하는지 생각해보자.
- HTTP 프로토콜에서 Socket 기반의 프로토콜로 바뀌면서, 처리해야하는 HTML 데이터가 String 에서 Byte 배열로 변경되었다.
만약 당장 구조를 변경할 수 없는 상황이라면, 우리는 꼼짝없이 아래의 Ex2 와 같이 변경할 수 밖에 없다.
위와 같은 경우 우리는 String 으로 처리된 Data 들을 전부 Array<Byte> 타입으로 일일이 변경해주어야하는 번거로움이 있고, 만약 놓친다면 오류를 맞닥뜨리게 된다.
책임이란?
Fig2 의 설계와 같은 문제점은 Fig1 에서 Data 가 하는 책임을 DataViewer 가 맡고 있기 때문에 발생하는 문제이다.
SRP 에서 우리가 중요하게 봐야하는 것은 책임에 관한 것이라고 생각한다. 그런데 책임은 어떻게 구분할 수 있을까? 이를 따질 때 고려해야하는 것이 변경될 가능성이 있는지 없는지와 관련된다.
만약 Fig2 와 같은 설계라고 하더라도, Http 통신 방식에서 변경될 가능성이 없고, 따라서 data 의 형태가 String 에서 변경될 가능성이 없다고 하면, 우리는 구지 Data 클래스로 추상화하여 클래스를 분리할 필요가 없다. 오히려 더 복잡한 구조만 갖는 셈이다.
즉 클래스를 정의하기 위해 단일 책임을 갖도록 설계하기 위해서는 변경되지 않는 범위가 무엇인지 구분하고, 클래스의 이름만으로도 어떤 역할을 하는지 알 수 있도록 작성하는 것이 유지 및 보수를 하는데 중요할 것이라고 생각한다.
SOLID 의 다른 원칙 바로가기
Reference
- 최범균, 2014, 객체지향과 디자인 패턴, 인투북스
- [Wikipedia] “SOLID” — https://en.wikipedia.org/wiki/SOLID
- [위키백과] “SOLID (객체 지향 설계)” — https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)
