단일 책임 원칙 (Single-Responsibility Principle SRP)
(C++ 소프트웨어 디자인 책 정리)
클래스를 변경하는 이유는 단 하나여야 한다.
모든 것은 오직 한가지 일만 해야 한다.
설명이 모호한데, 이 법칙의 아이디어는 항상 같다. 즉, 진정 함께 속하는 것만 하나로 묶고 엄격히 속하지 않는 것은 모두 분리한다.
바꿔말하면, 여러가지 이유로 변경하는 것을 분리한다.
이렇게 함으로써 코드의 서로 다른 관심사 사이에 인위적인 결합을 낮추고 소프트웨어가 변경에 . 더 잘 적응할 수 있게 돕는다.
최선의 경우 소프트웨어의 특정 측면을 정확히 한 곳에서 변경할 수 있다.
인위적인 결합 예
코드 예제로 관심사 분리를 설명해 보자. 아래 Document 추상 클래스 보면,
class Document
{
public:
// ...
virtual ~Document() = default;
virtual void exportToJSON( /*...*/ ) const = 0;
virtual void seriallize( ByteStream&, /*...*/ ) const = 0;
// ...
};
이 Document 클래스는 변경이 쉽지 않기 때문에 SRP 위반의 좋은 예시이다.
Docmument 에서 파생된 클래스와 Document 클래스 사용자는 여러가지 이유로 변경되는데, 다음과 같은 이유로 변경할 수 있다.
- 사용한 JSON 라이브러리에 대한 직접적인 의존성 때문에 exportToJSON() 함수 구현 상세가 바뀐다.
- 바탕 구현 내용이 바뀌기 떄문에 epxortToJSON() 함수 시그니처가 바뀐다.
- ByteStream 클래스에 대한 직접적인 의존성 때문에 Document 클래스와 serialize() 함수가 바뀐다.
- 구현 상세에 관한 직접적인 의존성 때문에 serialize() 함수의 구현 상세가 바뀐다.
아래와 같이 UML 그리면 JSON, ByteStream 같은 라이브러리에 의존성이 생긴다.
즉 여러가지 이유로 변경하는 것을 변형점(variation point)으로 분리한다.
class Document
{
public:
// ...
virtual ~Document() = default;
// virtual void exportToJSON( /*...*/ ) const = 0;
// virtual void seriallize( ByteStream&, /*...*/ ) const = 0;
// ...
};
'Language > C++ Design Pattern' 카테고리의 다른 글
Visitor 패턴 (1) | 2025.02.02 |
---|---|
DIP 원칙 (0) | 2025.01.30 |
LSP 원칙 (0) | 2025.01.30 |
OCP 원칙 (0) | 2025.01.29 |
ISP 원칙 (0) | 2025.01.29 |