SOLID 원칙

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

SRP 단일 책임 원칙

Single Responsibiity Principle

• 한 클래스는 하나의 책임만 가져야 한다.
• 변경이 있을 때 파급 효과가 적으면 SRP를 잘 따른 것

OCP 개방-폐쇄 원칙

Open/Closed Principle

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다
• 역할과 구현의 분리

public class MemberService {
	// MemberRepository m = new MemoryMemberRepository(); // 기존 코드
	MemberRepository m = new JdbcMemberRepository();   // 변경 코드
}

• (문제점) 다형성을 사용했지만 OCP를 지킬 수 없다.
• (해결책) 별도의 조립을 하는 설정자가 필요 -> Spring Container

LSP 리스코프 치환 원칙

Liskov Substitution Principle

• 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스를 바꿀 수 있어야 한다.
• 단순히 컴파일에 성공하는 것을 넘어서는 이야기

Ex) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능
--> 뒤로 가게 구현하면 LSP 위반.

ISP 인터페이스 분리 원칙

Interface Segregation Principle

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

DIP 의존관계 역전 원칙

Dependency Inversion Principle

• 프로그래머는 추상화 의존 (O), 구체화 의존 (X)
• 구현 클래스에 의존해지 말고 인터페이스에 의존하라.
• 역할에 의존하게 해야 한다.

의존한다?
그 코드에 대해 하는 것.

public class MemberService {
	// MemberRepository m = new MemoryMemberRepository(); // 기존 코드
	MemberRepository m = new JdbcMemberRepository();   // 변경 코드
}

기존 코드에서 MemberService는 MemberRepository만 알고 있는 것이 아니라, MemoryMemberRepository도 알고 있음.
이러면 구체화에 의존함. 역할에 의존하는 것이 아님.
DIP 위반

---

정리

• 객체 지향의 핵심은 다형성
• 다형성만으로는 쉽게 부품을 갈아 끼우듯 개발할 수 없다.
• 다형성만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
• 다형성만으로는 OCP, DIP를 지킬 수 없다.
• 뭔가 더 필요하다. -> Spring

객체 지향 설계와 Spring

• DI(Dependency Injection): 의존 관계, 의존성 주입
• DI Container 제공
  스프링은 위 기술로 다형성 + OCP, DIP가 가능하도록 지원한다.