1. SRP(단일 책임 원칙) S
모든 클래스는 하나의 책임만 갖고, 하나의 책임만을 갖기 때문에 그 책임을 완전히 캡슐화
- 캡슐화: 외부로부터 자세한 구현을 숨김
응집성 원칙에 근거
어떠한 클래스나 모듈은 변경되려는 단 하나의 이유만을 가져야 한다.
e. g.) 보고서를 편집하고, 출력하는 모듈
- -> 1. 보고서때문에, 2. 출력때문에 변경될 수 있음
- 분리된 두 책임이기 때문에, 클래스나 모듈로 나뉘어야 함.
변경이 있을 때, 영향이 적게 미치면 SRP대로 잘 나눈 것?
2. OCP(개방-폐쇄 원칙)
- 기존 코드를 변경하지 않으면서(closed), 기능을 추가할 수 있도록(open) 설계 하기
- 객체지향에서 가능한 동작을 단위별로 추상화를 통해 묶을 수 있음.
- 추상화: 데이터 명세와 구현을 분리. 인터페이스 분리 등
- 고정되기는 해도, 제한되지는 않게 가능한 동작끼리 묶어 추상화.
3. LSP(리스코프 치환 원칙)
- 상위 타입의 객체를 하위 타입의 객체로 치환해도 프로그램은 정상적으로 동작해야 한다.
- 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 해야함.
- 위반 예시 : 직사각형class로부터 정사각형 class를 파생하는 경우
- 정사각형 객체가 직사각형을 다루는 context에서 사용되는 경우 정사각형 크기는 독립적으로 변경 불가능.
- 정사각형의 “각 변이 같다”는 조건을 유지하면, 직사각형에서 “각 변은 독립적이다”라는 조건을 무력화(위반)한다.
- 위반을 하더라도, 위의 조건과 같은 조건이 사용이 되지 않는다면 문제가 되지 않을 수도 있긴 하다.
4. ISP(인터페이스 분리 원칙)
- 클라이언트는 자신이 사용하지 않는 인터페이스는 구현하지(의존하지) 말아야 한다.
- 인터페이스들을 최대한 작은 단위(역할 인터페이스)로 분리시켜 클라이언트는 필요한 메서드만 이용할 수 있도록
- e.g.) 자동차 클래스 -> 운전, 정비 클래스로 바꾸면, 추후 클라이언트 -> 운전자, 정비사 클래스로 나눌 수 있고, 하나의 변경이 다른 하나의 변경에 영향을 미치지 않는다.
5. DIP(의존 역전 원칙)
- 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.
- 추상화에 의존, 구체화에 의존 x
- e.g.) JPA를 사용해 hibernete 본체에 의존하지 않는 것
Reference)
https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5%EC%84%A4%EA%B3%84)
https://siyoon210.tistory.com/155
https://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%B1%85%EC%9E%84_%EC%9B%90%EC%B9%99
https://doublem.org/SOLID_SRP_OCP/
https://hckcksrl.medium.com/solid-%EC%9B%90%EC%B9%99-182f04d0d2b