스프링의 핵심
: 객체지향언어의 특징을 극대화해준다.
Q. 객체지향언어의 특징이 무엇인가?
객체지향이란?
프로그램을 객체단위로 바라보는 것.
- 장점 : 프로그램을 유연 & 변경 용이하도록 도움.
객체지향의 특징 : 추상화, 캡슐화, 상속, 다형성
그 중 다형성을 알아보자.
다형성이란?
프로그램을 역할, 구현으로 구분지어 바라보는 것.
-> 유연 & 변경 용이하게 해줌.
다형성의 본질
- 구현체를 실행시점에 유연하게 변경 가능.
- 클라이언트 변경 없이, 구현 기능 유연히 변경 가능.
확장가능하다 : memberRepository 예시.
다형성의 한계
- 인터페이스가 변경되면 클라이언트-서버에 변경 발생.
스프링이 이러한 특성을 극대화시켜주는 것
좋은 객체지향 설계의 5원칙 (SOLID)
SRP ( 단일 책임 원칙 )
- 한 클래스는 하나의 책임만을 가져야한다.
기준 = "변경". 만약 변경시 파급효과가 적으면 잘 지켜진 것.
OCP ( 개방-폐쇄 원칙 )
- 확장에는 열려있고, 변경에는 닫혀있다.
예시: memberRepo 아래에 기능을 추가하여 확장할 수 있다. 하지만 클라이언트에서는 코드 변경이 없어야 한다.
문제점 : memberService에서 jdbcRepo->memoryRepo로 바꿀시 코드 변경해야함.
LSP ( 리스코프 치환 원칙 )
- 컴파일이 문제없이 됨과 상관 없이, 특정한 기능은 그 기능에 맞게 수행되어야한다.
예시: 엑셀 밟았더니 뒤로 감. 그래도 실행은 된 것. 하지만 자신의 역할을 제대로 수행하지 않음.
ISP (인터페이스 분리 원칙 )
- 인터페이스 잘 쪼개야함. 크게 하나로 하기보단, 될 수 있는한 나누는게 좋다.
이유: 코드 변경시, 크게 하나로 뭉쳐있었다면 여러 곳에 영향을 미칠 수 있음.
DIP ( 의존관계 역전 원칙 )
- 개발자는 구현체가 아닌 역할에 의존해야함.
예시: memberRepo에서의 예시와 같음. service가 구현체(memoryRepo)에 의존하면, 구현체 변경시 service(클라이언트)의 코드를 변경해야하는 문제 발생.
정리
다형성 만으로는 OCP, DIP 지킬 수 없음
-> 스프링이 이를 도와줌 (DI, IoC 이용하여)
다형성이 무조건 좋을까?
X. 추상화라는 비용 발생.
코드 변경이 없을 것으로 보인다면, 인터페이스 없이 구현체로만 개발하여도 좋을 것임.
저스트두잇