해당 게시글은 실무 자바 개발을 위한 OOP와 핵심 디자인 패턴 강의를 참고해서 작성한 게시글임을 밝힙니다.
SOLID
SOLID 탄생 배경
의존성을 잘 관리하기 위해 따라야 하는 원칙들을 정리하는 과정에서 탄생
SRP, 단일 책임 원칙
하나의 클래스는 하나의 책임만을 가져야 한다.
책임 = 변경하려는 이유.
- HTTP 말고 다른 식으로 요청을 받을 것이면 컨트롤러만 바꾸면 된다.
- 기능이 변경 되면 서비스만 바꾸면 된다.
- 데이터베이스가 바뀌면 레포만 바꾸면 된다.
"~할때 바뀌어야 한다" 라고 말할때, "~" 가 책임이다.
우리가 잘 모를때 단일 책임 원칙이 깨지는 경우
서비스 레이어에서 상태코드를 return 한다면?
HTTP 통신을 다른 걸로 바꾸면 서비스 함수도 변경 해야함.
단일책임 원칙을 지킬때 이점
각각 클래스가 응집력이 높아 재사용성이 높아지고, 캡슐화를 통해 한 클래스의 변경이 다른 클래스에 영향을 미치지 않도록 만든다.
OCP, 개방-폐쇄 원칙
소프트웨어는 확장에는 열려있고 변경에는 닫혀 있어야 한다.
확장 = 소프트웨어에 새로운 기능을 추가하는 것.
확장에 열려있다 = 새로운 기능을 추가해도 사용하는 측에서 코드 변화가 없다.
인터페이스를 통해 구현한다고 많이 알려져있지만, enum, 디자인 패턴, 이벤트 기반 구조 등으로도 구현할 수 있다.
개방-폐쇄 원칙을 지킬때 이점
클라이언트 코드가 추상화에 의존하기 때문에 확장과 변경 될때 다른 코드에 영향을 주지 않는다.
LSP, 리스코프 치환 원칙
부모클래스가 할 수 있는 행동은 자식클래스도 할 수 있어야 한다.
(= 파생 클래스는 기반 클래스를 대체할 수 있어야 한다.)
만약 부모클래스에서 모든 정수를 처리할 수 있는 함수가, 자식 클래스에서 양수만 받을 수 있게 override 된다면?
- 다형성을 구현할 수 없음.
- instance of 로 확인을 해서 실행하면 코드가 지저분해 진다.
- 사전 조건 (파라미터 등..)은 자식 클래스에서 더 강해지면 안됨. (계약에 의한 조건 일부)
리스코프 치환 원칙을 지킬때 이점
진정한 의미에서의 다형성을 제공해주기 때문에, 코드의 분기 없이도 올바르게 확장 가능한 코드를 만든다.
ISP, 인터페이스 분리 원칙
클라이언트별로 세분화 된 인터페이스를 만들어야 한다.
사용하지 않는 메서드를 구현해야 하는 인터페이스는 사용하면 안된다.
인터페이스 분리 원칙을 지킬때 이점
구현 클래스에 불필요한 메서드를 구현하지 않도록 만들고, 인터페이스를 사용하는 클래스에게는 불필요한 메서드를 노출시키지 않아 유지보수 하기 좋은 코드를 만들어 준다.
DIP, 의존 역전 원칙
고수준 컴포넌트는 저수준 컴포넌트에 의존 해서는 안된다.
예외를 던질때
같은 인터페이스를 사용하는 구현체는 예외도 인터페이스로 만들어서 던져야 한다.
예외처리로 인해 의존성이 생길 수 있음.
의존 역전 원칙을 지킬때 이점
인터페이스를 통해 고수준 컴포넌트가 저수준 컴포넌트에 의존하지 않기에, 저수준 컴포넌트 변경이 고수준까지 전파되지 않는다.
