티스토리 뷰

웹개발/Java

SRP 단일 책임의 원칙

야쿠 yaku 2010.12.30 13:35

SRP (Single Responsibility Principle, 단일 책임의 원칙)

 

Note

단일 책임의 원칙은 함수나 메소드를 개발할 때의 바람을 객체 차원에서 가지게 될 때 제대로 지켜질 것이다.

우리는 함수나 메소드를 개발할 때 하나의 함수가 하나의 동작에 대해 책임을 다하기를 바랄 것이다. 마찬가지로 우리는 하나의 객체가 단 하나의 "객체" 로서의 책임을 다 할 수 있도록 해주어야 한다. 추상적인 책임이 아닌 시스템 상에서의 책임을 의미함에 주의하자. 데이터를 "저장"하는 책임이라는 추상적인 의미로 객체에 책임을 부여했을 경우를 생각해보자. 단지 저장하나에 대한 책임을 주었음에도 불구하고, 해당 객체는 하나의 객체가 가지는 책임의 범위를 넘어서는 형태가 될 수 있다.

 srp01.jpg

<<3-1. 여러가지 책임을 가지는 객체>>

 3-1의 그림에서 보듯이 추상적인 의미의 저장을 잘 표현하지만 사실 Storage라는 객체는 이미 세 종류의 책임을 가진다. 길게 풀어본다면 우선 각 매체의 처리에 대한 책임을 가지게 된다. 파일을 쓸수 있는 상태인지 DB는 연결 가능한 상태인지 실패 했을 때에는 또 어떤 식으로 상태를 반환 하겠는가. 아마 개발을 진행하면서 자주 겪게 되는 상황이 아닌가 싶다. 3-1의 그림이 보여주는 최악의 상황은 그 이상일 수 있다. 현업에 배포된 Storage 객체에 또 다른 매체가 추가되는 경우를 상상해보자. 운이 좋다면 새로운 매체에 대한 새로운 클라이언트가 생기는 것에서 일단락 되는 상황이 가능하겠지만 재수 없는 경우(많은 경우가 이 경우에 해당하지 않을까?) 이미 Storage 클래스를 사용 중인 나머지 클라이언트 모두가 수정되어야 하는 이른바 "산탄총 수술"이라는 상황을 겪게 될 것이다. 또 클라이언트 중의 하나의 요구사항이 변경된 다거나 저장하는 기능에 대한 요구 사항이 변경되는 경우를 보면 또 "여러 원인에 의한 변경"이라는 상황을 맞이 하게 될 것이다.

두 상황은 모두 나쁘지만 더 나쁘게될 위험이 있다는 점에서 확실히 나쁘다. "저장"이라는 책임은 확실히 하나의 객체에 요구 하면서 각 매체에 대한 책임은 분리해 주는 것이 이 상황을 해결은 방법이라 하겠다.

 

Keypoint
  • SRP는 대상이 함수나 메소드가 아닌 객체라는 점에 주목해야 한다.

    • 객체는 둘 이상의 책임 갖지 않는 형태를 가져야 한다. 즉, 두개 이상의 메소드나 프로퍼티를 가졌을 때 책임이 그 수만큼 늘어나게 된다면 과감하게 분리한다.(Extract Class, Extract Method)
  • SRP는 하나의 객체가 두개의 책임을 가지는 것 만큼이나 두개의 객체가 하나의 책임을 나누는 것에 주의를 기울여야 한다.

    • 단일 요구사항의 변경으로 둘 이상의 객체가 변경을 요하는 상황에 처 한다면, 책임이 나뉘었다고 판단하고, 하나의 객체가 온전히 책임을 다 가질 수 있도록
      해주어야 한다. (Move Method, Move Field)

 

 

둘 이상의 책임을 가진 객체에 대한 처리.
  1. Extract Class를 고려한다.
  2. Extract Class에 의해 분리된 클래스들에 중복되거나 유사한 책임을 가지는 경우 Extract superclass를 시도한다.

 ocp02.jpg

<<3-2. 책임은 분리하고, 중복은 제거하는 방법>>

 

하나의 책임이 둘 이상의 객체로 분리된 경우에 대한 처리
  1. 기존의 클래스 중 책임을 가질 클래스로 Move Field를 고려한다. 그럴 만한 클래스가 없다면 새로운 클래스를 만든다.
  2. 이동한 Field에 대해 Move Method를 진행한다.
  3. 책임이 거의 대부분 다른 곳으로 옮겨 감으로써 클래스로서 존재 의미가 없는 경우 inline class를 진행한다.
  4. 책임이 전혀 없거나 기능을 상실한 클래스 또는 메소드는 Remove Class 또는 Remove Method를 진행한다.

 srp02.jpg

<<3-3. 책임이 분리된 형태>>      

srp03.jpg 

<<3-4. inline class 및 Remove Class>>

 

참고자료

객체지향 5원칙 : http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039135552

산탄총 수술에 대한 Refectoring 기법: http://blog.daum.net/bellosogno/10

 


'웹개발 > Java' 카테고리의 다른 글

DIP 의존관계 역전원칙  (0) 2010.12.30
LSP 리스코프 치환의 원칙  (0) 2010.12.30
SRP 단일 책임의 원칙  (0) 2010.12.30
OCP 개방 폐쇄 원책  (0) 2010.12.30
ISP 인터페이스 분리의 원칙  (1) 2010.12.30
oAuth 의 시나리오  (1) 2010.12.17
댓글
댓글쓰기 폼