반응형
SOLID 디자인 원칙, 로버트 마틴(Uncle bob)에 의해 소개되었던 자료는 아래 링크에서 살펴볼 수 있습니다.
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
클래스는 하나의 책임만 가져야 하며, 그 책임을 수행하는 하나의 이유만 있어야 한다는 원칙입니다. 이를 위반하는 사례와 수정된 예제를 통해 설명하겠습니다.
SRP 위반 사례
아래 예제는 SRP를 위반하고 있습니다. Employee 클래스는 직원 정보를 저장하면서 동시에 직원 정보를 파일로 저장하는 기능도 수행하고 있습니다. 이는 "직원 정보 관리"와 "파일 입출력"이라는 두 가지 책임을 가지고 있어 SRP를 위반합니다.
#include <iostream>
#include <fstream>
#include <string>
class Employee {
private:
std::string name;
int id;
public:
Employee(const std::string& name, int id) : name(name), id(id) {}
std::string getName() const { return name; }
int getId() const { return id; }
// 직원 정보를 파일로 저장하는 기능
void saveToFile(const std::string& filename) {
std::ofstream file(filename);
if (file.is_open()) {
file << "ID: " << id << "\n";
file << "Name: " << name << "\n";
file.close();
}
}
};
int main() {
Employee employee("John Doe", 123);
employee.saveToFile("employee.txt");
return 0;
}
위의 Employee 클래스는 직원 정보뿐 아니라 직원 데이터를 파일에 저장하는 기능도 가지고 있습니다. 파일 저장 기능은 Employee 클래스의 책임이 아니므로 SRP를 위반합니다. 이로 인해 만약 파일 저장 방식이 변경되거나 다른 입출력 형식을 추가할 경우, Employee 클래스에 변경이 발생할 수 있습니다.
SRP를 적용한 코드
SRP를 적용하여 Employee 클래스와 파일 입출력을 담당하는 클래스를 분리하겠습니다. Employee 클래스는 직원 정보를 관리하고, EmployeeFileManager 클래스는 파일 입출력을 전담하도록 변경합니다.
#include <iostream>
#include <fstream>
#include <string>
class Employee {
private:
std::string name;
int id;
public:
Employee(const std::string& name, int id) : name(name), id(id) {}
std::string getName() const { return name; }
int getId() const { return id; }
};
class EmployeeFileManager {
public:
// 직원 정보를 파일에 저장하는 기능을 담당
static void saveToFile(const Employee& employee, const std::string& filename) {
std::ofstream file(filename);
if (file.is_open()) {
file << "ID: " << employee.getId() << "\n";
file << "Name: " << employee.getName() << "\n";
file.close();
}
}
};
int main() {
Employee employee("John Doe", 123);
EmployeeFileManager::saveToFile(employee, "employee.txt");
return 0;
}
- Employee 클래스는 이제 직원 정보만 관리하며, 파일 입출력 기능은 없습니다.
- 파일 입출력은 EmployeeFileManager 클래스가 전담하도록 분리했습니다.
- 이렇게 수정함으로써 Employee 클래스는 "직원 정보 관리"라는 단일 책임만 갖게 되었고, 파일 저장과 관련된 코드 변경이 필요할 경우 EmployeeFileManager 클래스만 수정하면 됩니다.
이처럼 Single Responsibility Principle을 지키면 클래스의 변경 요인을 줄이고 코드 유지보수를 쉽게 만들 수 있습니다.
'프로그래밍 일반 > 객체 지향' 카테고리의 다른 글
Inheritance(상속) 그리고 Composition(구성) (0) | 2019.11.17 |
---|---|
Boost.DI 소개 (0) | 2019.11.10 |
SOLID 디자인 원칙 (0) | 2019.11.03 |
Mixin 이란? (0) | 2019.11.03 |
이상한 재귀 템플릿 패턴(Curiously Recurring Template Pattern, CRTP) (0) | 2019.10.27 |