* SRP (Single Responsibility Princicple; 단일 책임 원칙)
> A class should have only one reason to change.
(클래스는 변경할 때 한 가지 이유만 있어야 한다. 클래스는 작고 단일 목적을 추구해야 한다)
* 함수는 반드시 하나의, 단 하나의 일만 해야 한다는 원칙이다
* 'reason to change (변경의 이유)' 란 바로 이들 사용자와 이해관계자를 가리킨다
> 하나의 모듈은 하나의, 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다
* 해당 변경을 요청하는 한 명 이상의 사람들이라고 할때, Actor 라고 바꾸어 다시 정의하면,
> 하나의 모듈은 하나의, 오직 하나의 Actor 에 대해서만 책임져야 한다
* 하나의 모듈은 함수와 데이터 구조로 구성된 응집된 (cohesive) 집합이다
> 단일 actor 를 책임지는 코드를 함께 묶어주는 힘이 바로 응집성 (cohesion) 이다
* 메서드와 클래스 수준의 원칙이다. 하지만, 이보다 상위 수준에서도 다시 등장한다
> 컴포넌트 수준에서는 Common Closure Principle (공통 폐쇄 원칙) 이 된다
> 아키텍처 수준에서는 Architectural Boundary (아키텍처 경계) 의 생성을 책임지는 Axis of Change (변경의 축) 이 된다.
> 소프트웨어 시스템이 가질 수 있는 최적의 구조는 시스템을 만드는 조직의 사회적 구조에 커다란 영향을 받는다.
따라서, 각 소프트웨어 모듈은 변경의 이유가 하나, 단 하나여야만 한다.
* Soution
> coupled responsibilities 를 각각의 클래스로 분리한다
* Cohesion 가 높을수록 SRP 가 잘 지켜지고 있다고 볼 수 있다
'SW 공학 > 아키텍처 & 디자인' 카테고리의 다른 글
///SOLID Principle (0) | 2020.10.03 |
---|---|
/////DIP (Dependency Inversion Principle) (0) | 2020.09.26 |
/////ISP (Interface Segregation Principle) (0) | 2020.09.26 |
/////LSP (Liskov Substitution Principle) (0) | 2020.09.26 |
/////OCP (Open-Closed Principle) (0) | 2020.09.26 |