SOLID : 좋은 객체 지향 설계의 5가지 원칙

SRP 단일 책임 원칙

Single Responsibility Principle

한 클래스는 하나의 책임만 가진다.

한 파일에 view, DB접근, 쿼리까지 모두 들어가있으면 유지보수가 어렵고 코드도 복잡해진다.

---

OCP 개방-폐쇄 원칙

Open / Closed Principle

확장에는 열려있고, 변경에는 닫혀있어야 한다.

다형성과 같다.
예를 들어, 자동차(부모) - 테슬라(자식), 아반떼(자식) 와 같은 구조에서 새로운 차 제네시스를 추가해도 Driver운전자 코드는 변경할 필요가 없다.
(구현 코드를 하나 더 만드는 것(제네시스 추가)은 변경하는 것이 아니다.)

⚠️ OCP의 문제점

public class MemberService {
//	private MemberRepository memberRepository = new MemoryMemberRepository();
    private MemberRepository memberRepository = new JdbcMemberRepository();
}

MemberService 라는 클라이언트가 구현 클래스를 직접 선택하고 있다.
구현 객체를 Memory리포지토리에서 Jdbc리포지토리로 바꾸려면 코드 자체를 수정해야한다. 변경에는 닫혀있어야 한다는 OCP를 위반하는 것이다.
(이 관계의 설정자 역할을 추후에 Spring이 해주게 됨)

---

LSP 리스코프 치환 원칙

Liskov Substitution Principle

상속받은 클래스가 부모 클래스의 규약을 깨뜨리면 안된다는 원칙
자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 한다.

단순히 컴파일이 된다고해서 끝나는 것이 아니다.
예를 들어, 악셀 기능은 앞으로 나가도록 해야지 뒤로 가게 하면 안된다. 설령 뒤로가게 해도 컴파일에 문제는 없겠지만 말이다.
따라서 사전에 약속한 기획대로 구현하고, 상속 시 부모에서 구현한 원칙을 따라야 한다.
(인터페이스를 구현한 구현체를 믿고 사용하기 위함. 다형성을 위한 원칙이다.)

---

ISP 인터페이스 분리 원칙

Interface Segregation Principle

하나의 커다란 인터페이스보다는 여러개의 구체적인 작은 인터페이스로 분리해야한다.

예를 들어, 하나의 커다란 자동차 인터페이스를 운전과 정비인터페이스로 나누는 것이다.
이 경우 정비에 문제가 생겨도 운전에는 영향을 미치지 않게된다.
인터페이스의 역할을 명확하게 나누고 대체 가능성을 높이기 위함이다.

---

DIP 의존관계 역전 원칙

Dependency Inversion Principle

추상화에 의존해야지, 구체화에 의존하면 안된다.

public class MemberService {
//	private MemberRepository memberRepository = new MemoryMemberRepository();
    private MemberRepository memberRepository = new JdbcMemberRepository();
}

MemberService 클라이언트가 구현클래스를 직접 선택하고 있다. = 의존하고 있다.
이는 구체화에 의존하면 안된다는 DIP를 위반하는 행위다.