Day 개발 기록
3부 - 설계 원칙 본문
좋은 소프트웨어의 규칙에 관한 내용이다. Clean Code로 부터 시작하는 소프트웨어의 원칙을 설명한다.
함수 & 데이터 구조를 클래스로 배치하고 클래스들을 서로 결합하는 방법에 대해 알아본다.
SOLID 법칙
- SRP : 단일 책임 원칙 : 각 소프트웨어의 모듈 변경이유는 하나 일 것
- OCP : 개방-폐쇄 원칙 : 기존 코드를 수정하지 않고 새로운 코드를 추가하는 방향으로
- LSP : 리스코프 원칙 : 상호대체 가능하게 설계할것. 구성요소간 서로 치환이 가능하도록 한다.
- ISP : 인터페이스 분리 원칙 : 각각의 인터페이스는 분리한다.
- DIP : 의존성 역전 원칙 : 저수준 코드 ← 고수준 으로 의존 해서는 안된다. 세부사항이 고수준의 정책에 의존하는 방향으로 설계할 것.
1. SRP
하나의 모듈은 하나의 이해관계 집단 즉, 하나의 액터들에 의존하도록한다.
우발적 중복
다른 액터가 의존하는 코드를 서로 가까이 배치하지 않는다.
병합
변경사항이 서로 충돌하는 경우 병합이 발생할 수 있다.
→ 해결 : 각 메소드를 각 클래스로 옮긴다. 퍼사드 패턴으로 고치는 방법도 있다.
2. OCP 개방폐쇄
artifact (소프트웨어)는 확장은 항상 열려있고 변경사항엔 항상 닫혀있을 것.
방법 : SRP를 지키고 각 의존성을 떨어뜨리면 된다.
모든 컴포넌트의 방향은 서로 단방향이 되도록 한다.
ex ) Controller → Interface(고수준 정보) 이때 , Controller를 Interface로 부터 보호하기 위해서
Interface의 내부를 은닉한다.
컴포넌트는 정보 단위로 분리한다.
고수준 컴포넌트를 저수준 컴포넌트로 부터 보호하는 의존성 계층구조를 만든다.
3. LSP : 리스코프의 원칙
구성요소간 서로 치환되도록 한다. 상속의 이용에 대해 설명한다.
4. ISP : 인터페이스 분리
정적타입으로 정의된파일을 오퍼레이션 단위로 분리한다.
5. DI : 의존성 역전
유연성이 극대화된 시스템은 소스코드 의존성이 추상에 의존하며 구체에 의존하지 않는다.
쉽게말해서 변하기 쉬운 클래스에 의존하지 않는다.
* 인터페이스, 추상클래스와 같은 것에만 의존하도록 한다.
* 변동성이 큰 구체적인 요소에 의존을 피하려 해야한다.
<방법>
변동성이 큰 구체 클래스를 참조하지 않는다.
변동성이 큰 구체 클래스로 부터 파생하지 않는다.
구체함수를 오버라이드 하지 않는다.
구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 않는다.
추상클래스: 고수준의 업무규칙을 포함한다.
구체컴포넌트 : 세부사항에 대한 내용을 포함한다.
'Reading > Clean Architecture' 카테고리의 다른 글
2부 - 패러다임의 개요 (0) | 2020.07.30 |
---|---|
1부 설계와 아키텍쳐란? (0) | 2020.07.30 |