OOP - SOLID 원칙 1.단일 책임의 원칙(SRP, Single Responsibility Principle)

• SOLID 원칙

로버트 마틴이 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙

디자인패턴 및 스프링 프레임워크의 기본 설계(사상) 또한 SOLID 원칙을 기초로 함

 

• 단일 책임의 원칙, Single Responsibility Principle [ ˈsɪŋɡl rɪ|spɑːnsə│bɪləti  ˈprɪnsəpl ]
• 개방-폐쇄 원칙, Open-Closed Principle
• 리스코프 치환 원칙, Liskov Substitution Principle [ |sʌbstɪ│tuːʃn ]
• 인터페이스 분리 원칙, Interface Segregation Principle [ ˌseɡrɪˈɡeɪʃn ]
• 의존관계 역전 원칙,  Dependency Inversion Principle [  dɪˈpendənsi ɪn│vɜːrʃʒn ]

 

응집도와 결합도

SOLID 원칙에 앞서 응집도와 결함도에 대해 숙지해야 한다. 좋은 소프트웨어 설계는 결합도는 낮고, 응집도는 높은 설계를 말한다.

 

결합도 : 모듈(클래스 세부적으로는 메소드도 포함) 간의 상호 의존성(영향력)이 낮아야 객체의 재사용과 유지보수가 유리하다.

응집도 : 하나의 모듈 내부에 존재하는 구성요소들의 기능적인 관련성을 나타내며, 응집도가 높다는 것은 하나의 모듈에 하나의 책임을 집중시켜, 독립성을 높이며, 객체의 재사용 및 유지보수가 용이하게 된다.

 

 

 

단일 책임의 원칙, Single Responsibility Principle

클래스와 함수는 단 하나의 기능(목적)을 위해 설계되어야 한다. 

새로운 요구사항과 프로그램 변경에 영향을 받는 부분이 적으며, 응집도는 높고, 결합도는 낮은 프로그램을 말한다.

하나의 메소드가 내부 로직에서 책임지는 역할이 많으면(처리하는 로직이 여러 가지라면...) 섣불리 내부를 변경하기 어렵고, 결과적으로 유지보수(시간, 비용, Risk)가 어렵게 된다. 

 

어떤 클래스(메소드)를 설계하는 경우에는 반드시 하나의 책임(기능)만 가지도록 설계해야 한다.

어떤 클래스(메소드)를 변경하는 경우에도 반드시 하나의 책임을 유지하는 원칙을 벗어나는 변경을 하면 안된다.

 

[AS-IS]

• 학생 클래스
  • 과목 관련된 책임(역할)도 수행
  • 출석 관련된 책임(역할)도 수행
  • 책임이 늘어날수록 코드가 복잡해지고, 로직이 무거워지며, 유지보수가 어려워짐

• 기능 수정사항이 발생한다면 무슨일이 생길까?
  
  • 수강 과목 변경 기능이 필요하게 되면?
    • Student에 수강 과목 변경 메소드 추가
    • 기존 클래스에 영향 X
  • 과목에 강의 시간 정보가 추가된다면?
    
    • Attendance 클래스(VO)에 강의시간 멤버 변수 추가 
    • getStudent에 강의시간 정보 조회 로직 추가 - 조금 더 복잡도 증가
  • 학생에 관리할 정보가 추가되면 어떻게 되나? 동아리, 봉사활동, 과목 성적 ...
    • 동아리 클래스(VO) 생성
    • Student 클래스에 동아리 멤버 변수 정의
    • Student 클래스에 동아리 등록, 동아리 조회 등 메소드 추가
    • getStudent 메소드에 동아리 정보 조회 로직 추가
    • 기존 클래스(Student) 기존 메소드(getStudent) 수정 발생
    • getStudent를 사용하던 기존 로직 모두에 필요 여부와 무관하게 동아리 정보 추가 제공됨
      : 로직 복잡, 성능 문제 발생, 유지보수 비용 증가

[TO-BE]

• 학생, 과목, 출석
  • 각각의 클래스가 하나의 책임(역할)만 하고 있음
  • 학생 정보에 추가 요구사항(예-학번 추가)이 발생해도 나머지 설계에 영향이 없음
  • 불필요하게 기능이 커지지 않음(예-getStudent)기능 수정사항이 발생한다면 무슨일이 생길까?
    • 수강 과목 변경 기능이 필요하게 되면?
      • AttendanceService에 수강 과목 변경 메소드 추가
      • 기존 클래스에 영향 X
    • 과목에 강의 시간 정보가 추가된다면?
      
      • Attendance VO에 강의시간 멤버 변수 추가 
      • 기존 클래스에 영향 X
    • 학생에 관리할 정보가 추가되면 어떻게 되나? 동아리, 봉사활동, 과목 성적 ...
      • 동아리 클래스(VO) 생성
      • 동아리 서비스 클래스 생성
      • 동아리 등록, 동아리 조회 등 메소드 추가
      • 기존 클래스에 영향 X

 

 

 

인터넷에서 OOP SOLID 원칙를 설명하는 글과 클래스 다이어그램이 많이 있지만, 내용 설명에 부족함을 느껴서 위와 같은 자료를 만들었습니다. 퍼가시는 것은 관계없으나 출처를 밝혀 주시면 감사하겠습니다.