스프링은 Java 언어 기반의 프레임워크
➡️ Java 언어의 가장 큰 특징은 객체 지향 언어라는 것
➡️ 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
➡️ ❗좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크
✅ 스프링 부트는 서버를 내장 (Tomcat)
빌드할 때, 빌드 결과(Jar) WAS 서버(Tomcat)를 포함
➡️ 빌드 배포 단순화
<출처 : https://www.edureka.co/blog/videos/building-web-application-using-spring-framework/ >
✅ 가장 중요한 것은 다형성!
역할(인터페이스)과 구현(인터페이스를 구현한 클래스, 구현 객체)으로 세상을 구분
➡️ 세상이 단순해지고, 유연해지며 변경도 편리해진다.
클라이언트는 구현 대상의 내부 구조가 변경되어도, 구현 대상 자체를 변경하여도 영향을 받지 않으며 클라이언트는 대상의 역할(인터페이스)만 알면 됨
따라서 객체 설계시에 인터페이스를 먼저 부여하고, 그 역할을 수행하는 구현체를 만든다.
홀로 존재하는 객체는 없음
수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가짐
클라이언트 : 요청, 서버: 응답
다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경 가능
이름이 같은 오버라이딩, 오버로딩한 메서드 중 해당하는 메서드를 실행시점에 결정하여 실행하는 것처럼
클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있음
❗인터페이스를 수정하지 않도록 안정적으로 잘 설계하는 것이 정말 중요 (예시 - API)
SRP 단일 책임 원칙
-> 변경이 있을 때, 파급 효과가 적어야 함 (책임[역할] 분리)
⭐OCP 개방-폐쇄 원칙
-> 확장에는 열려있으나 변경에는 닫혀있어야
-> 인터페이스의 변경은 No, 구현체의 확장은 OK
그러나 클라이언트(Service)가 구현 클래스를 직접 선택하는 경우
구현 객체를 변경하려면 클라이언트 코드를 변경해야 함
-> 다형성을 사용해도 OCP 원칙을 지킬 수 없음
예시)
public class MemberService {
MemberRepository mr = new MemoryMemberRepository(); // 기존 코드
MemberRepository mr = new JdbcMemberRepository(); //변경하려는 코드
}
LSP 리스코프 치환 원칙
-> 하위 클래스는 인터페이스의 규약을 지켜야 함
ISP 인터페이스 분리 원칙
-> 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 나음
⭐DIP 의존관계 역전 원칙
-> 클라이언트 코드는 구현 클래스에 의존하지 않고, 인터페이스에 의존해야 함
-> 역할에 의존해야 한다
그러나 OCP의 문제 상황으로 든 예시의 경우
MemberService는 인터페이스에 의존하지만, 동시에 구현 클래스도 의존한다.
-> DIP 위반
스프링은 DI, DI 컨테이너로 다형성 + OCP, DIP를 가능하게 지원한다.
➡️ 클라이언트 코드의 변경 없이 기능 확장 가능
❓실무 고민
이상적으로는 모든 설계에 인터페이스를 부여하는 것이 좋음
그러나 인터페이스를 도입하면 추상화라는 비용이 발생함
-> 구현 클래스가 무엇인지 코드를 다시 확인해야 함
따라서 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용,
향후 꼭 필요한 경우에 리팩터링하여 인터페이스를 도입
인프런 스프링 핵심 원리 - 기본편 (김영한) 참조