[스프링 핵심 원리 - 기본편] Section 1. 객체 지향 설계와 스프링

SPRING

- 자바 언어 기반 프레임워크
- 자바: 객체 지향 언어
- 좋은 객체 지향 어플리케이션을 개발할 수 있게 도와주는 프레임워크
 

역할과 구현 분리

클라이언트는

1. 대상의 역할(인터페이스)만 알면 됨
2. 구현 대상의 내부 구조를 몰라도 됨
3. 구현 대상의 내부 구조가 변경되어도 영향 받지 않음
4. 구현 대상 자체를 변경해도 영향을 받지 않음

자바

1. 역할 = 인터페이스
2. 구현 = 인터페이스를 구현한 클래스, 구현 객체
3. 객체 설계 시 역할을 먼저 부여, 그 역할을 수행하는 구현 객체 만들기

 

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

S : SRP 단일 책임 원칙(Single responsibility principle)

• 한 클래스는 하나의 책임만 가져야 함
  •  하나의 책임? - 클 수도 있고 작을 수도 있음, 문맥과 상황에 따라 다름
• 중요한 기준은 변경: 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것

O: OCP 개방 - 폐쇄 원칙(Open/closed principle)

• 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀 있어야 함
• "다형성"을 활용
• 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현 > 기존 코드를 변경하는 것이 아님
• 역할과 구현의 분리 생각 !!!!
• 문제점
  • MemberService 클라이언트가 구현 클래스를 직접 선택
  • MemberRepository m = new MemoryMemberRepository(); (기존)
  • MemberRepository m = new JdbcMemberRepository(); (변경)
  • 코드 변경 필요....
  • 다형성을 사용했지만 OCP 원칙이 지켜지지 않음
  • 객체 생성, 연관관계 조립, 설정자 > spring의 역할

L: LSP 리스코프 치환 원칙(Liskov substitution principle)

• 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 함
• 다형성의 하위 클래스는 인터페이스 규약을 다 지켜야 함, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체를 사용하려면 필요
• 컴파일 성공 뿐만 아니라 ~
• ex. 엑셀 기능: 뒤로 가게 구현 (LSP 위반)

I: ISP 인터페이스 분리 원칙(Interface segregation principle)

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 나음
• 자동차 인터페이스: 운전 인터페이스 + 정비 인터페이스
• 사용자 클라이언트: 운전자 클라이언트 + 정비사 클라이언트
• 정비 인터페이스가 변해도 운전자 클라이언트에 영향 X
• 인터페이스 명확, 대체 가능성 높아짐

D: DIP 의존관계 역전 원칙(Dependency inversion principle)

• "추상화에 의존해야지, 구체화에 의존하면 안된다."
• 구현 클래스에 의존 X 인터페이스에 의존 O
• 역할(Role)에 의존해야 하는 것 !! 클라이언트가 인터페이스에 의존해야 유연하게 구현체 변경이 가능함
• 이슈
  • MemberService 클라이언트가 구현 클래스 직접 선택
  • MemberRepository m = new MemoryMemberRepository(); (DIP 위반)
  • MemberService는 MemberRepository 인터페이스에만 의존해야 함

 
"다형성 만으로는 OCP, DIP를 지킬 수 없음"

 
 

---

 

1. 모든 설계에 역할과 구현을 분리
2. 이상적으로는 모든 설계에 인터페이스를 부여하자
3. 인터페이스 도입 > 추상화 비용 발생,,
4. 구체 클래스를 직접 사용, 필요할 때 리팩토링해서 인터페이스를 도입해도..됨