자바 ORM 표준 기술
JPA (80%하이버네이트, 이클립스, 기타...)
스프링 역사
유겐 휠러, 얀 카로프가 로드 존슨에게 오픈소스 프로젝트 제안
EJB 문제점 지적 오픈소스 복붙해서 사용한 것
스프링 프레임워크, 스프링 부트 (필수)
스프링 데이터, 세션, 시큐리티, Rest Docs, 배치, 클라우드는 선택이다.
핵심 기술 : 스프링 DI컨테이너, AOP, 이벤트, 기타
웹 기술 : 스프링 MVC, 스프링 WebFlux
데이터 접근 기술 : 트랜잭션, JDBC, ORM 지원, XML 지원
기술 통합 : 캐시, 이메일 ,원격접근, 스케줄링
테스트 : 스프링 기반 테스트 지원
언어 : 코틀린, 그루비
스프링을 편리하게 사용할 수 있도록, 기본으로
스프링 애플리케이션 쉽게 생성
Tomcat같은 웹서버 내장 -> 웹 서버 설치하지 않아도 된다.
손쉬운 빌드 구서을 위한 starter 종속성 제공
스프링과 3rd parth(외부) 라이브러리 자동 구성
메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공한다
관례에 의한 간결한 설정
스프링의 핵심 개념?
자바 언어 기반 프레임워크 (객체 지향 언어)
객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크
추상화
캡슐화
상속
다형성 : 역할과 구현으로 세상을 구분한다. 역할과 구현으로 구분하고, 변경도 편리해진다.
객체를 설계할 때 역할(인터페이스)와 구현(역할을 수행하는)을 명확히 분리
클라이언트 : 요청
서버 : 응답 객체 클라이언트와 객체 서버는 협력 관계를 가진다.
클라이언트 -> 서버
클라이언트 -> 서버 + 클라이언트 -> 서버
오버라이딩은 자바 기본 문법
메서드가 실행된다. 다형성으로 인터페이스를 구현한 객체를 실행 시점에 변경 가능하다.
부모는 마음이 넓기 때문에 자식들을 다 품을 수 있다. ㅋㅋㅋ
SRP : 단일 책임 원칙
하나의 클래스는 하나의 책임만 가져야 한다. 중요한 기준은 변경이다.
OCP : 개방-폐쇄 원식
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. = 다형성을 활용하고
인터페이스를 구현한 새로운 클래스를 만들어서 새로운 기능을 구현한다.
구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다.
다형성을 사용했지만 OCP원칙을 지킬 수 없다. -> 기존 코드를 변경해야 한다.
객체를 생성하고, 연관관계를 맺어주는 조립, 설정자가 필요하다.
LSP : 리스코프 치환 원칙
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다.
ISP : 인터페이스 분리 원칙
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
DIP : 의존 관계 역전 원칙
프로그래머는 추상화에 의존해야 하며, 구체화에 의존하면 안된다. 역할에 의존해야 한다.
구현 클래스에 의존하지 말고, 인터페이스에 의존해야 한다. 역할에 의존하게 해야 하고, 구현에 의존하면 안된다. 다형성 만으로 OCP, DIP를 지킬 수 없다.
DI(Dependency Injection) : 의존관계, 의존성 주입
클라이언트 코드의 변경 없이 기능 확장된다.
쉽게 부품을 교체하듯이 개발한다. DI 컨테이너
모든 설계에 역할과 구현을 분리하여야 한다.
모든 설계에 인터페이스를 부여하자. 추상화라는 비용이 발생한다.
기능을 확장할 가능성이 없다면, 리팩터링해서 인터페이스를 도입하는 것도 방법이다.