[클린 아키텍처] 설계 원칙 SOLID
SOLID
- 함수와 데이터 구조를 클래스로 배치하는 방법, 이 클래스들 서로 결합하는 방법
- 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다.
SRP - 단일 책임 원칙
- 하나의 모듈은 하나의 엑터에 대해서만 책임져야하는 원칙
- SRP 원칙에 위반되면 한 가지 기능을 서로 다른 엑터들이 사용(의존) 하고 있을 때 해당 함수가 하나의 엑터의 요구에 따라 변경되면 나머지 엑터들은 원치않는 변경으로 인해 오류가 발생할 수 있다
- 또 각각의 엑터에서 한 기능에 의존 시 동시 수정으로 인해 병합 시 충돌 발생이 생길 수 있다.
-> 각각의 엑터가 각각의 기능으로 의존할 수 있게 분리 필요
-> 각각의 엑터에 각각의 클래스를 생성하여 데이터만 가진 클래스를 공유 - 개발자가 각각의 클래스를 추적해야하는 단점이 있다.
-> 퍼사드 패턴을 통해 한 클래스에서 각가의 클래스를 인스턴스화 하여 퍼사드 클래스의 사용 함수에 맞게 해당 클래스를 위임
*엑터 - 하나 이상의 사용자 또는 하나 이상의 이해관계자 집단
OCP - 개방 폐쇄 원칙
- 확장에 열려있고 변경에는 닫혀있어야 하는 원칙
- 서로 다른 목적으로 변경되는 요소를 분리(SRP), 요소들 사이 의존성을 체계화 함으로(DIP) 해당원칙을 지킬 수 있다.
- 발생 상황에 따라 기능은 분리하고 기능을 컴포넌트 계층구조로 조직화하여 저수준에서 발생한 수정으로 부터 고수준의 컴포넌트를 보호
-> 확장이 쉬워지고 변경으로 인한 다른 시스템에 영향이 줄어든다.
* 추이종속성 - A가 B를 의존하고, B가 C를 의존하면 A는 C를 의존
LSP - 리스코프 치환 원칙
- S타입 객체 o1, T타입 객체 o2가 있을 때 T타입으로 정의한 모든 프로그램 P 에서 o2를 o1으로 치환해도 P의 행위가 바뀌지 않는다면 S는 T의 하위타입
- 같은 인터페이스를 구현하는 두 객체는 치환하여도 사용객체 행위가 바뀌지 않는 원칙
-> 구현체에 의존하지 않아야함
ISP - 인터페이스 분리 원칙
- 두개 이상의 기능을 가진 객체를 하나의 기능만을 위해 사용한다면 불필요하게 사용하지 않는 기능에도 의존될 수 있다.
-> 객체의 기능을 각각으로 가진 인터페이스를 통해 구현하고 사용 클래스는 사용할 기능의 추상을 가진 인터페이스를 의존하여 해결
- 필요 이상으로 많은 기능이 포함된 모듈의 의존은 좋지않음.
DIP - 의존성 역전 원칙
- 추상적인 대상에 의존하고 구체적인 대상엔 의존을 피해야하는 원칙
-> 운영체제나 플랫폼 같이 안정성이 보장된 구체는 예외 ex) String
- 피해야할 대상은 구체적이며 변동성이 큰 요소
- 인터페이스의 변동성은 낮추고, 구현체의 기능을 추가할 수 있는 방법을 강구해야한다.
- 추상 컴포넌트는 애플리케이션의 고수준 업무규칙을, 구체 컴포넌트는 업무 규칙을 다루기 위해 필요한 세부사항을 포함한다.
-> 제어흐름은 소스코드 의존성과 반대로 흐른다.
- 변동성이 큰 구체 참조 X - 추상을 참조
- 변동성이 큰 구체로부터 파생(상속) X - 추상을 구현
- 구체함수 오버라이드 X -> 추상함수로 선언하고 구현체에 각 용도에 맞게 구현
- 구체적이고 변동성이 크면 의존 X