*인프런 김영한 강사님의 강좌를 참고하여 정리한 내용입니다.*클린코드의 저자 로버트 마틴이 정리한 좋은 객체 지향 설계의 5원칙
1. SRP 단일 책임 원칙 (Single Responsibility Principle)
- 하나의 클래스가 존재할 때, 변경이 있을 때 클래스에 미치는 파급 효과가 적다면 단일 책임의 원칙을 잘 따른 것이다!
- 클래스의 책임을 적절하게 조절하는것이 중요하다.
ex) 객체의 생성과 사용을 분리한다. 어떠한 요구사항으로 인한 변경이 생길 때 사용을 담당하는 부분만 수정할 수 있도록
2. OCP 개방-폐쇄 원칙 (Open/ Closed Principle)
- 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀있어야 한다.
- 다형성을 활용하여 역할과 구현을 구분하게 되면, 역할(인터페이스)은 변경하지 않고 구현(클래스)의 확장을 할 수 있다!
[문제점]
클라이언트가 구현 클래스를 직접 선택하는 경우, 필요한 클래스를 변경할 수 있다. 이런 경우에는 OCP 원칙을 위반하게 된다. 분명 다형성을 활용했지만 OCP 원칙이 지켜지지 않았다.
3. LSP 리스코프 치환 원칙 (Liskov Substitution Principle)
- 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것이다. 다형성을 지원하기 위한 원칙으로 인터페이스는 구현한 구현체를 믿고 사용하려면 이러한 원칙이 필요하다.
ex) 자동차 인터페이스의 엑셀은 앞으로 가는 기능이지만 뒤로 가는 자동차를 오버라이딩 하여 구현하게 된다면 인터페스의 규약을 위반, 한 마디로 LSP를 위반한것이다.
4. ISP 인터페이스 분리 원칙 (Interface Segregation Principle)
- 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다!
- 분리 원칙을 통해 인터페이스의 역활이 더 명학해지고, 대체 가능성이 높아진다.
ex) 자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스, 부가기능 인터페이스 등으로 분리
5. DIP 의존관계 역전 원칙 (Dependency Inversion Principle)
- 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. (클라이언트 코드가 구현이 아닌 인터페이스에만 의존해야 한다)
- 구현체에 의존하게 된다면 변경이 아주 어려워진다!
[문제점]
위의 OCP원칙의 문제점과 비슷하게 클라이언트가 인터페이스에 의존하지만, 구현 클래스를 직접 선택하면서 구현 클래스에도 동시에 의존하는 경우
따라서..
객체 지향의 핵심은 다형성이다. 하지만 다형성 만으로는 DIP, OCP 원칙에 위배되는 경우가 발생하여 변경이 어려워질 수 있다. 그렇기떄문에 Spring이 필요하다.
dev