SOLID 원칙 (1)

SOLD 원칙

---

Goal

• 단일 책임 원칙에 대해서 이해할 수 있다.
• 개방-폐쇄 원칙에 대해서 이해할 수 있다

---

 

 

1. 단일 책임 원칙

 

소프트웨어 설계 첫 번째 원칙으로 SRP(Single Responsibility Principle)라는 단일 책임 원칙이 있다.

문자 그래도 단 하나의 책임을 가지는 것이다.

SRP에서 기본 단위는 객체를 지칭한다. 즉, 개체는 하나의 책임을 가져야 한다는 의미이다.

 

"책임"이란 여러 관점에서 해석될 수 있지만 보통 '해야 하는 것'과 '할 수 있는 것'으로 간주할 수 있다.

 

학생 클래스

 

예를 들어 학생(Student) 클래스에는 수강과목 조회, 추가를 하거나 학생 정보를 저장, 출력을 하거나 학생 성적표, 출석표를 출력할 수 있는 기능이 있다. 

 

 현재 Student 클래스는 단일 책임 원칙에 의하여 단 하나의 책임을 가져야 하지만 여러 가지의 책임(기능)을 수행하고 있다.

 위의 코드의 문제점은 학생 클래스에서 변경사항이 생기면 연관되어 있는 모든 메소드에 영향을 주기 때문에 영향을 받은 메서드와 관련된 모든 기능을 테스트해야 하는 불편함이 있다. 따라서 각 기능들을 분리하는 것이 좋다.

 단일 책임 원칙을 따르기 위해서는 한 가지의 책임만을 수행해야한다. 따라서 학생(Student) 클래스에서 가장 잘 수행할 수 있는 책임은 학생 수강 과목 조회 및 추가하는 기능이다.

 

좋은 설계란?

기본적으로 시스템에 새로운 요구사항이나 변경이 있을 때 가능한 한 영향받는 부분을 줄여야 한다. 

어떤 클래스가 잘 설계되었는지를 판단하려면 언제 변경되어야하는지 생각해봐야 한다. 

학생 클래스를 예를들어보자.

 

• 데이터베이스의 스키마가 변경된다면  Studnet 클래스도 변경되어야 하는가?
• 학생이 지도 교수를 찾는 기능이 추가되어야 한다면 Student 클래스는 영향을 받는가?
• 학생 정보를 성적표와 출석부 이외의 형식으로 출력해야 한다면 어떻게 해야 하는가?

학생의 출석부를 출력하는 기능, 학생부를 출력하는 기능을 각각의 클래스로 분리하고 학생의 정보 저장하고 조회하는 기능은 학생 DAO에서 할 수 있도록 변경한다.

학생

※ DAO(Data Access Object) : DB에 접속하여 조회, 출력 등을 할 수 있는 기능을 전담하는 오브젝트이다.

 

 

출석부, 성적표에 출력을 담당하는 성적표 클래스와 출석부 클래스로 분리하면 학생 클래스에서 변화가 생겨도 영향을 최소화할 수 있으며 학생의 정보를 출력할 수 있는 방법이 추가가 되어도 기존의 코드에 영향을 최소화하면서 추가할 수 있다. 또한 데이터베이스 변화되면 학생 DAO 클래스나 이를 사용하는 클래스만 영향을 받는다.

 

 

2. 개방-폐쇄 원칙

 

개방-폐쇄 원칙(Open-Closed Principle)은 요구사항이 생기면 기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있도록 하는 설계가 되어야 한다는 뜻이다. 

 

학생

Some Client에서 출석부와 성적표를 통해서 학생의 정보를 가져오는데 만약 학생의 도서 기록부를 조회할 수 있는 기능을 추가한다면 위와 같은 구조에서는 OCP 원칙을 위배하게 된다.

왜냐하면 Client에서 도서기록부를 조회하는 코드가 추가가 되어야 하기 때문이다.

 

OCP에 위반되지 않는 설계를 하기 위해서는 항상 무엇이 변경되어야 하는지 그리고 무엇이 변경되면 안 되는지를 구분을 해야 한다.

기존 코드들은 최대한 변경하지 않으면서 도서 기록부(변하는 것)를 추가해야 한다.

 

 

위의 구조와 같이 Client가 어떤 요청을 하면 인터페이스를 통해서 구체적인 출력 매체를 캡슐화해 처리하도록 해야 한다.  따라서 클라이언트 클래스가 어떤 동작을 실행할 때 클라이언트에 영향을 주지 않고 쉽게 동작을 확장할 수 있다.

 

 

1. 개체는 하나의 책임만 가지도록 설계

2. 새로운 수정사항이 생겼을 때 기존 코드가 최대한 수정되지 않으면서 기능을 추가할 수 있도록 설계