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

uglyduck.dev·2020년 9월 27일
1

개념 모아 🗂

목록 보기
27/40

정의

  • 단 하나의 책임만을 가지는 원칙으로써, 객체지향 뿐만 아니라 절차적 프로그래밍 기법에도 적용되는 개념

책임

  • '해야 하는 것' 혹은 '할 수 있는 것'
  • 객체지향 설계 관점에서 봤을때 객체에 책임을 할당할 때는 어떤 객체보다도 작업을 잘 할 수 있는 객체에 책임을 할당해야 함
  • 책임에 수반되는 모든 일을 자신만이 수행할 수 있어야 함

ex) Student 클래스

public class Student {
    public void getCourses() {...} // 수강 과목 조회
    public void addCourses(Course c) {...} // 수강 과목 저장
    
    ...
    public void save() {...} // 데이터베이스 객체 정보 저장
    public Student load() {...} // 데이터베이스 객체 정보 조회
    public void printOnReportCard() {...} // 성적표 출력
    public void printOnAttendanceBook() {...} // 출석부 출력
}

문제점

  • Student 클래스는 너무나 많은 책임을 수행함
  • 가장 잘할 수 있는 것 -> 수강 과목 추가 및 조회
  • 학생 정보 저장, 데이터베이스로부터 객체 조회, 성적표화 출석부를 출력은 다른 클래스가 더 잘할 수 있는 여지가 있음

해결

  • 수강 과목을 추가하고 조회하는 책임만 수행

변경

  • 좋은 설계란 기본적으로 시스템에 새로운 요구사항이나 변경이 있을 때 가능한 한 영향 받는 부분을 줄여야 함

  • 어떤 클래스가 잘 설계되었는지를 판단하는 척도는 "언제 변경되었는가?"

Student 클래스는 언제,왜 변경해야 하는가?

  • 데이터베이스의 스키마가 변경된다면 Student 클래스도 변경되어야 하는가?

  • 학생이 지도 교수를 찾는 기능이 추가되어야 한다면 Student 클래스는 영향을 받는가?

  • 학생 정보를 성적표와 출석부 이외의 형식으로 출력해야 한다면 어떻게 해야 하는가?
    변경의 영향

  • 책임이 많이 질수록 클래스 내부에서 서로 다른 역할을 수행하는 코드끼리 강하게 결합될 가능성이 높아짐

책임분리

Q. Student 클래스의 여러 책임을 수행한다면?

A. Student 클래스에 변경사항이 생기면 Student 클래스를 사용하는 코드와 전혀 관계가 없더라도 직접 또는 간접적으로 사용하는 모든 코드를 다시 테스트해야 함

※ TIP
어떤 변화가 있을 때 해당 변화가 기존 시스템의 기능에 영향을 주는지 평가하는 테스트를 회귀테스트라 함

  • 회귀테스트
    • 시스템에 변경이 발생할 때 기존의 기능에 영향을 주는지를 평가하는 테스트
  • 모든 코드를 테스트하는 문제를 해결하려면 한 클래스에 너무 많은 책임을 부여하지 말고 단 하나의 책임만 수행하도록 해 변경 사유가 될 수 있는 것을 하나로 만들어야 함

책임 분리

Student 클래스의 변경 사유

  • 학생의 고유 정보
  • 데이터베이스 스키마
  • 출력 형식의 변화

Student 클래스의 개선된 설계

개선된 디자인

  • 학생 클래스(학생 고유의 역할 수행)
  • 학생 DAO 클래스(데이터베이스에 저장, 조회)
  • 성적표 클래스(성적표 출력)
  • 출석부 클래스(출석부 출력)

Reference

  • 정인상, 채흥석, 『JAVA 객체 지향 디자인 패턴』, 한빛미디어(2019.3.8), 104~108p
profile
시행착오, 문제해결 그 어디 즈음에.

0개의 댓글