[컴퓨터공학]/[소프트웨어공학]

[소프트웨어공학] SOLID - 단일 책임 원칙(Single Responsibility Principle)

딥러닝 도전기 2022. 5. 1. 20:35

[소프트웨어공학] SOLID - 단일 책임 원칙(Single Responsibility Principle)

 

객체 지향 설계 5원칙 SOLID

SOLID란 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 의미합니다. 대규모 프로그램에서 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 적용해야 합니다. 다섯 가지 기본 원칙은 다음과 같습니다.

 

1. Single Responsibility Principle, 단일 책임 원칙

2. Open-Closed Principle, 개방-폐쇄 원칙

3. Liskov Substitution Principle, 리스코프 치환 원칙

4. Interface Segregation Principle, 인터페이스 분리 원칙

5. Dependency Inversion Principle, 의존성 역전 원칙


객체 지향 설계 원칙은 위의 다섯 가지 원칙의 앞글자를 따서 SOLID라고 합니다. 

이번 포스팅에서는 첫 번째 원칙인 단일 책임 원칙에 대해 다루도록 하겠습니다.

 


단일 책임 원칙(Single Responsibility Principle)

 

“A class should have one, and only one reason to change”

 

단일 책임 원칙이란 "한 개의 클래스는 단 한 개의 책임을 가져야 한다" 라는 내용입니다. 

"책임"은 클래스가 담당하는 동작을 의미하며, 한 클래스의 책임이 많아질 수록 해당 클래스의 변경에 따른 영향이 매우 커집니다. 만약 한 개의 클래스에 여러 개의 책임이 있다면, 이는 결합도를 증가시킵니다. 소프트웨어 설계는 결합도의 증가를 지양하는 방향으로 진행되어야 합니다. 단일 책임 원칙을 준수하지 않은 예시와 준수한 예시를 살펴보면 다음과 같습니다.

 

 

단일 책임 원칙을 따르지 않은 예시

public class Task{
	public void downloadFile(String location){
    	//download file
    }
    
	public void parseFile(File file){
    	//parse the file
    }
    
	public void persistData(Data data){
    	//persist the data
    }
}

 

위의 예시는 Task라는 한 개의 클래스 안에 downloadFile, parseFile, persistData의 세 가지 책임이 있습니다. 이는 단일 책임 원칙을 위배한 예시입니다. 한 클래스의 책임이 많아질수록 객체지향 코드와는 멀어지고 절차지향적인 코드가 됩니다. 이를 단일 책임 원칙에 따라 수정하면 다음과 같습니다.

 

단일 책임 원칙을 준수한 예시

public class downloadFileTask{
	public void downloadFile(String loaction){
	//download file
    }
}

public class parseFileTask{
	public void parseFile(File file){
	//parse file
    }
}

public class persistDataTask{
	public void persistData(Data data){
	//persist data
    }
}

원래는 한 개의 Task 클래스에 있었던 세 가지 책임(동작, 메서드)을 단일 책임 원칙에 맞추어 각자의 클래스를 생성한 후 할당해 주었습니다.

 

하지만 단일 책임 원칙에서 "단일"이라는 것은 매우 상대적인 부분으로, 꼭 한 개의 클래스 내에 한 개의 메서드만 구현되어야 하는 것은 아닙니다. 되도록 작은 단위로 구현되면 좋지만, 분리될 이유가 없는데 분리가 된다면 불필요한 복잡성이 증가하게 됩니다.

반응형