[스프링 핵심 원리 - 기본편] 섹션1 - 객체 지향 설계와 스프링
스프링 핵심 원리 - 기본편 - 인프런 | 강의
스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런...
www.inflearn.com
본 내용은 인프런의 스프링 핵심원리 내용을 정리한 글입니다. 모든 저작권은 위의 인프런 강의에 있습니다.
스프링의 탄생 배경
EJB라고 하는 자바 프레임워크는 너무 복잡해서 배우기 어렵고 EJB로 코딩하면 자바의 강점인 객체지향을 살리지 못한다. 자바의 객체지향의 장점을 살리기 위해서 만든게 스프링이다.
스프링의 핵심
스프링은 자바 언어 기반의 프레임워크
자바의 큰 장점 -> 객체 지향 언어
스프링은 객제 지향의 특징을 가장 잘 살린 프레임워크
스프링은 객체지향 애플리케이션을 개발을 도와주는 프레임워크
자바 구성
필수: 스프링 프레임워크, 스프링 부트
선택: 스프링 데이터, 스프링 세션, 스프링 시큐리티, 스프링 Rest Docs, 스프링 배치, 스프링 클라우드
스프링 프레임워크
핵심 기술- 스프링 DI 컨테이너, AOP, 이벤트 기타
웹 기술 - 스프링 MVC, 스프링 WebFlux
데이터 접근 기술 - 트랜잭션, JDBC, ORM 지원 XML 지원
- ORM?? Object Relational Mapping 즉, 객체 - 관계 매피의 줄임말이다. 객체를 구현한 클래스와 RDB(Relational Database)에서 쓰이는 데이터 테이블과 자동으로 매핑(연결)하는 것을 의미한다.
기술 통합: 캐시, 이메일, 원격접근, 스케줄링
테스트: 스프링 기반 테스트 지원
언어: 코틀린, 그루비
- 최근에는 스프링 부트를 통해 스프링을 편리하게 사용
자바의 특징
- 추상화
- 캡슐환
- 상속
- 다형성
다형성이란 여러 객체에게 동일한 명령을 내렸을 때 서로 다르게 반응하는 것이며 역할과 구현을 분리하여 변경에 편리
다형성을 구현하는 방법은 아래와 같다
- 인터페이스
- 추상클래스 - 선언부만 있고 구현부가 없는 메소드
- 메소드 오버라이딩
- 메소드 오버로딩
역할과 구현을 분리
이러한 특징 덕분에 클라이언트는
- 인터페이스만 알면 된다.
- 내부구조를 몰라도 된다.
- 내부구조가 변경돼도 영향을 받지 않음
- 구현 대상을 변경해도 영향을 받지 않음
자바의 다형성을 활용
- 역할 = 인터페이스
- 구현 = 인터페이스를 구현한 클래스, 구현 객체
- 객체를 설계할 때 역할과 구현을 명확하게 분리한다.
- 객체 설계시 역할(인터페이스)를 먼저 만들고, 그 역할을 수행하는 구현 객체 만들기
- 혼자있는 객체는 없으며 클라이언트는 요청, 서버는 응답
- 클라이언트와 서버는 협력관계를 가진다.
- 오버라이딩을 하면 다형성의 특징 덕에 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경 가능
- 클래스 상속 관계도 다형성, 오버라이딩 적용 가능.
스프링을 사용하면 마치 레고 조립하듯이 공연 무대의 배우를 선택하듯이 구현을 편리하게 변경할 수 있다,
좋은 객체 지향 설계 5가지 원칙(SOLID) _ 로버트 마틴
SRP 단일 책임 원칙
- 한 클래스는 하나의 책임만 가진다.
- 변경이 잇을때 파급 효과가 적으면 단일 원칙을 잘 따른 것
OCP 개방-폐쇄 원칙
소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀 있어야 한다.
MemberService 클라이언트가 구현 클래스를 선택해야하며 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다.
-> 다형성을 사용했지만 OCP원칙 위반 즉, 다른 방법이 필요
LSP 리스코프 치환 원칙
프로그램의 객체는 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야한다.
예) 자동차 인터페이스중 엑셀은 앞으로 가야하며 뒤로 가면 LSP위반이다. 느리더라도 앞으로는 가야한다.
ISP 인터페이스 분리 원칙
특정 클라이언트르 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
DIP 의존 관계 역전 원칙
프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다. 의존성 주입은 이 원칙을 따르는 방법 중 하나.
즉 인터페이스에 의존해라
위에 있는 MemberService는 인터페이스에 의존하지만 구현 클래스도 동시에 의존한다.
MemberService클라이언트가 구현 클래스를 직접 선택
MemberRepository m = new MemoryMemberRepository();
-> DIP 위반
객체지향은 다형성이며 다형성만으로는 쉽게 부품을 갈아 끼우듯 개발할 수 없으며 구현객체를 변경할 때 클라이언트 코드도 함께 변경된다.
다형성 만으로는 OCP, DIP를 지킬 수 없다. 무언가가 더 필요...