자바 진영의 추운 겨울과 스프링의 탄생
EJB: Enterprise Java Beans
- 장점: 이론적으로 좋음, ORM도 돼
- 단점: 수천만원, 느리고, 복잡하고, 어려움
스프링
- EJB를 비판하며 오픈소스로 만듦
하이버네이트
- EJB 비판하며 오픈소스로 만듦
- EJB 엔티티빈 기술을 대체
- JPA: 자바 표준 인터페이스
- 지금은 이러한 구조를 가짐
- 보통 하이버네이트가 80% 차지
스프링이란?
스프링은 여러가지 기술의 모음이다. 하나씩 간단하게 알아보자.
- 스프링 데이터: 데이터베이스의 종류가 많지만, 기본적인 CRUD는 다 비슷함, 이걸 편리하게 사용하고자 스프링 데이터를 사용함
- 가장 많이 사용: 스프링 데이터 JPA
- 스프링 시큐리티: 보안과 관련된 것
- 스프링 Rest Docs: API 문서와 테스트를 편하게 엮어서 문서화를 편하게 해주는 것
- 스프링 배치: 실무에서 다량의 데이터 (예를들어 천만개) 가 있을때, 한 번에 돌리기는 어려우므로, 배치단위로 처리함
- 스프링 클라우드: 클라우드와 관련된 것
이외에도 굉장히 많은 기술이 존재한다. 스프링 사이트 오버뷰에 들어가보면 다양한 프로젝트를 확인해 볼 수 있다.
하지만 핵심은 스프링 프레임워크고, 이 모든 기술들을 편하게 사용할 수 있도록 도와주는 게 스프링 부트다.
스프링 프레임워크
- 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타
- 웹 기술: 스프링 MVC, 스프링 WebFlux
- 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원
- 기술 통합: 캐시, 이메일, 원격접근, 스케줄링
- 테스트: 스프링 기반 테스트 지원
- 언어: 코틀린, 그루비
최근에는 스프링부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용한다.
스프링 부트
스프링을 편리하게 사용할 수 있도록 지원하며, 최근에는 기본으로 사용한다.
<장점>
- 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
- 예전에는 빌드하고, 톰캣서버 따로 받아서 설치하고, 그 톰캣 서버에 특정 위치에다가 빌드한 스프링으로 여튼 빌드하고 따로 다 설정해줘야해서 복잡하다.
- 지금은 몇 줄 치면 끝!
- Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨
- 손쉬운 빌드 구성을 위한 starter 종속성 제공
- 예전에는 라이브러리 쓰려면 하나씩 다 땡겨와야 했음
- 스프링과 3rd parth(외부) 라이브러리 자동 구성
- 버전을 다 챙겨서 다운로드 받을 수 있음
- 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
- 관례에 의한 간결한 설정
스프링 단어
문맥에 따라 다르게 사용된다.
- 스프링 DI 컨테이너 기술
- 스프링 프레임워크
- 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계
스프링의 핵심
<aside> 💡 자바 기반의 좋은 객체 지향 애플리케이션을 개발할 수 있게 해줌
</aside>
좋은 객체 지향 프로그래밍
- 추상화
- 캡슐화
- 상속
- 다형성
다형성
실세계와 객체지향을 1:1로 매칭하진 말고, 실세계의 비유정도로 이해하자. 만약 역할과 구현으로 세상을 구분한다면?
- 운전자-자동차를 예시로 들어보자. 3개의 자동차를 구현하고, 운전자는 자동차가 바뀌어도 운전을 못하진 않는다. 즉, 영향을 받지는 않는다.
- 무한한 확장이 가능함
- 클라이언트에게 영향을 주지 않고 새로운 기능을 추가할 수 있음
역할과 구현을 분리함으로써
- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
그래서 자바 언어의 다형성을 활용하면
- 역할 = 인터페이스
- 구현 = 인터페이스를 구현한 클래스, 구현 객체
다만, 역할과 구현을 분리하는 한계에는
- 역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생한다.
- 자동차를 비행기로 변경해야 한다면? 대본 자체가 변경된다면?
- 따라서 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.
스프링과 객체 지향
스프링에서는 다형성이 가장 중요하다. 다 다형성을 활용해서 IoC, DI 다 할 수 있다!!
SOLID 원칙
SRP : 단일 책임 원칙
- Single Responsibility Principle
- 한 클래스는 하나의 책임만 져야한다.
- 근데, 하나의 책임이라는 것은 모호하다. 따라서 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 SRP를 잘 따른 것이라고 할 수 있다.
ex) UI변경, 객체의 생성과 사용을 분리
OCP : 개방-폐쇄 원칙⭐
- Open/closed principle
- 확장에는 열려있으나 변경에는 닫혀있어야 한다.
- 다형성을 잘 활용해서 지킬 수 있다.
- 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하는 것은 기존 코드를 변경하는 것이 아님!
- 근데 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다. 분명 다형성을 사용했지만 OCP 원칙을 지킬 수 없다. 따라서 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.
LSP: 리스코프 치환 원칙
- Liskov substitution principle
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
- 단순히 컴파일에 성공하는 것을 넘어서는 이야기
ex) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP 위반, 느리더라도 앞으로 가야 함
ISP: 인터페이스 분리 원칙
- Interface Segregation Principle
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- 자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스로 분리
- 사용자 클라이언트 → 운전자 클라이언트, 정비사 클라이언트로 분리
- 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음
- 인터페이스가 명확해지고, 대체 가능성이 높아진다.
DIP: 의존관계 역전 원칙⭐
- Dependency inversion principle
- 프로그래머는” 추상화에 의존해야지, 구체화에 의존하면 안된다” 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
- 쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
- 앞에서 이야기한 역할에 의존하게 해야 한다는 것과 같다. 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다. 구현체에 의존하게 되면 변경이 아주 어려워진다.
📢해당 글은 김영한님의 스프링 핵심 원리 강좌를 기반으로 작성되었습니다.
자바 진영의 추운 겨울과 스프링의 탄생
EJB: Enterprise Java Beans
- 장점: 이론적으로 좋음, ORM도 돼
- 단점: 수천만원, 느리고, 복잡하고, 어려움
스프링
- EJB를 비판하며 오픈소스로 만듦
하이버네이트
- EJB 비판하며 오픈소스로 만듦
- EJB 엔티티빈 기술을 대체
- JPA: 자바 표준 인터페이스
- 지금은 이러한 구조를 가짐
- 보통 하이버네이트가 80% 차지
스프링이란?
스프링은 여러가지 기술의 모음이다. 하나씩 간단하게 알아보자.
- 스프링 데이터: 데이터베이스의 종류가 많지만, 기본적인 CRUD는 다 비슷함, 이걸 편리하게 사용하고자 스프링 데이터를 사용함
- 가장 많이 사용: 스프링 데이터 JPA
- 스프링 시큐리티: 보안과 관련된 것
- 스프링 Rest Docs: API 문서와 테스트를 편하게 엮어서 문서화를 편하게 해주는 것
- 스프링 배치: 실무에서 다량의 데이터 (예를들어 천만개) 가 있을때, 한 번에 돌리기는 어려우므로, 배치단위로 처리함
- 스프링 클라우드: 클라우드와 관련된 것
이외에도 굉장히 많은 기술이 존재한다. 스프링 사이트 오버뷰에 들어가보면 다양한 프로젝트를 확인해 볼 수 있다.
하지만 핵심은 스프링 프레임워크고, 이 모든 기술들을 편하게 사용할 수 있도록 도와주는 게 스프링 부트다.
스프링 프레임워크
- 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타
- 웹 기술: 스프링 MVC, 스프링 WebFlux
- 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원
- 기술 통합: 캐시, 이메일, 원격접근, 스케줄링
- 테스트: 스프링 기반 테스트 지원
- 언어: 코틀린, 그루비
최근에는 스프링부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용한다.
스프링 부트
스프링을 편리하게 사용할 수 있도록 지원하며, 최근에는 기본으로 사용한다.
<장점>
- 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
- 예전에는 빌드하고, 톰캣서버 따로 받아서 설치하고, 그 톰캣 서버에 특정 위치에다가 빌드한 스프링으로 여튼 빌드하고 따로 다 설정해줘야해서 복잡하다.
- 지금은 몇 줄 치면 끝!
- Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨
- 손쉬운 빌드 구성을 위한 starter 종속성 제공
- 예전에는 라이브러리 쓰려면 하나씩 다 땡겨와야 했음
- 스프링과 3rd parth(외부) 라이브러리 자동 구성
- 버전을 다 챙겨서 다운로드 받을 수 있음
- 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
- 관례에 의한 간결한 설정
스프링 단어
문맥에 따라 다르게 사용된다.
- 스프링 DI 컨테이너 기술
- 스프링 프레임워크
- 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계
스프링의 핵심
<aside> 💡 자바 기반의 좋은 객체 지향 애플리케이션을 개발할 수 있게 해줌
</aside>
좋은 객체 지향 프로그래밍
- 추상화
- 캡슐화
- 상속
- 다형성
다형성
실세계와 객체지향을 1:1로 매칭하진 말고, 실세계의 비유정도로 이해하자. 만약 역할과 구현으로 세상을 구분한다면?
- 운전자-자동차를 예시로 들어보자. 3개의 자동차를 구현하고, 운전자는 자동차가 바뀌어도 운전을 못하진 않는다. 즉, 영향을 받지는 않는다.
- 무한한 확장이 가능함
- 클라이언트에게 영향을 주지 않고 새로운 기능을 추가할 수 있음
역할과 구현을 분리함으로써
- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
그래서 자바 언어의 다형성을 활용하면
- 역할 = 인터페이스
- 구현 = 인터페이스를 구현한 클래스, 구현 객체
다만, 역할과 구현을 분리하는 한계에는
- 역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생한다.
- 자동차를 비행기로 변경해야 한다면? 대본 자체가 변경된다면?
- 따라서 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.
스프링과 객체 지향
스프링에서는 다형성이 가장 중요하다. 다 다형성을 활용해서 IoC, DI 다 할 수 있다!!
SOLID 원칙
SRP : 단일 책임 원칙
- Single Responsibility Principle
- 한 클래스는 하나의 책임만 져야한다.
- 근데, 하나의 책임이라는 것은 모호하다. 따라서 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 SRP를 잘 따른 것이라고 할 수 있다.
ex) UI변경, 객체의 생성과 사용을 분리
OCP : 개방-폐쇄 원칙⭐
- Open/closed principle
- 확장에는 열려있으나 변경에는 닫혀있어야 한다.
- 다형성을 잘 활용해서 지킬 수 있다.
- 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하는 것은 기존 코드를 변경하는 것이 아님!
- 근데 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다. 분명 다형성을 사용했지만 OCP 원칙을 지킬 수 없다. 따라서 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.
LSP: 리스코프 치환 원칙
- Liskov substitution principle
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
- 단순히 컴파일에 성공하는 것을 넘어서는 이야기
ex) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP 위반, 느리더라도 앞으로 가야 함
ISP: 인터페이스 분리 원칙
- Interface Segregation Principle
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- 자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스로 분리
- 사용자 클라이언트 → 운전자 클라이언트, 정비사 클라이언트로 분리
- 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음
- 인터페이스가 명확해지고, 대체 가능성이 높아진다.
DIP: 의존관계 역전 원칙⭐
- Dependency inversion principle
- 프로그래머는” 추상화에 의존해야지, 구체화에 의존하면 안된다” 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
- 쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
- 앞에서 이야기한 역할에 의존하게 해야 한다는 것과 같다. 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다. 구현체에 의존하게 되면 변경이 아주 어려워진다.
📢해당 글은 김영한님의 스프링 핵심 원리 강좌를 기반으로 작성되었습니다.
자바 진영의 추운 겨울과 스프링의 탄생
EJB: Enterprise Java Beans
- 장점: 이론적으로 좋음, ORM도 돼
- 단점: 수천만원, 느리고, 복잡하고, 어려움
스프링
- EJB를 비판하며 오픈소스로 만듦
하이버네이트
- EJB 비판하며 오픈소스로 만듦
- EJB 엔티티빈 기술을 대체
- JPA: 자바 표준 인터페이스
- 지금은 이러한 구조를 가짐
- 보통 하이버네이트가 80% 차지
스프링이란?
스프링은 여러가지 기술의 모음이다. 하나씩 간단하게 알아보자.
- 스프링 데이터: 데이터베이스의 종류가 많지만, 기본적인 CRUD는 다 비슷함, 이걸 편리하게 사용하고자 스프링 데이터를 사용함
- 가장 많이 사용: 스프링 데이터 JPA
- 스프링 시큐리티: 보안과 관련된 것
- 스프링 Rest Docs: API 문서와 테스트를 편하게 엮어서 문서화를 편하게 해주는 것
- 스프링 배치: 실무에서 다량의 데이터 (예를들어 천만개) 가 있을때, 한 번에 돌리기는 어려우므로, 배치단위로 처리함
- 스프링 클라우드: 클라우드와 관련된 것
이외에도 굉장히 많은 기술이 존재한다. 스프링 사이트 오버뷰에 들어가보면 다양한 프로젝트를 확인해 볼 수 있다.
하지만 핵심은 스프링 프레임워크고, 이 모든 기술들을 편하게 사용할 수 있도록 도와주는 게 스프링 부트다.
스프링 프레임워크
- 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타
- 웹 기술: 스프링 MVC, 스프링 WebFlux
- 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원
- 기술 통합: 캐시, 이메일, 원격접근, 스케줄링
- 테스트: 스프링 기반 테스트 지원
- 언어: 코틀린, 그루비
최근에는 스프링부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용한다.
스프링 부트
스프링을 편리하게 사용할 수 있도록 지원하며, 최근에는 기본으로 사용한다.
<장점>
- 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
- 예전에는 빌드하고, 톰캣서버 따로 받아서 설치하고, 그 톰캣 서버에 특정 위치에다가 빌드한 스프링으로 여튼 빌드하고 따로 다 설정해줘야해서 복잡하다.
- 지금은 몇 줄 치면 끝!
- Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨
- 손쉬운 빌드 구성을 위한 starter 종속성 제공
- 예전에는 라이브러리 쓰려면 하나씩 다 땡겨와야 했음
- 스프링과 3rd parth(외부) 라이브러리 자동 구성
- 버전을 다 챙겨서 다운로드 받을 수 있음
- 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
- 관례에 의한 간결한 설정
스프링 단어
문맥에 따라 다르게 사용된다.
- 스프링 DI 컨테이너 기술
- 스프링 프레임워크
- 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계
스프링의 핵심
<aside> 💡 자바 기반의 좋은 객체 지향 애플리케이션을 개발할 수 있게 해줌
</aside>
좋은 객체 지향 프로그래밍
- 추상화
- 캡슐화
- 상속
- 다형성
다형성
실세계와 객체지향을 1:1로 매칭하진 말고, 실세계의 비유정도로 이해하자. 만약 역할과 구현으로 세상을 구분한다면?
- 운전자-자동차를 예시로 들어보자. 3개의 자동차를 구현하고, 운전자는 자동차가 바뀌어도 운전을 못하진 않는다. 즉, 영향을 받지는 않는다.
- 무한한 확장이 가능함
- 클라이언트에게 영향을 주지 않고 새로운 기능을 추가할 수 있음
역할과 구현을 분리함으로써
- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
그래서 자바 언어의 다형성을 활용하면
- 역할 = 인터페이스
- 구현 = 인터페이스를 구현한 클래스, 구현 객체
다만, 역할과 구현을 분리하는 한계에는
- 역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생한다.
- 자동차를 비행기로 변경해야 한다면? 대본 자체가 변경된다면?
- 따라서 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.
스프링과 객체 지향
스프링에서는 다형성이 가장 중요하다. 다 다형성을 활용해서 IoC, DI 다 할 수 있다!!
SOLID 원칙
SRP : 단일 책임 원칙
- Single Responsibility Principle
- 한 클래스는 하나의 책임만 져야한다.
- 근데, 하나의 책임이라는 것은 모호하다. 따라서 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 SRP를 잘 따른 것이라고 할 수 있다.
ex) UI변경, 객체의 생성과 사용을 분리
OCP : 개방-폐쇄 원칙⭐
- Open/closed principle
- 확장에는 열려있으나 변경에는 닫혀있어야 한다.
- 다형성을 잘 활용해서 지킬 수 있다.
- 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하는 것은 기존 코드를 변경하는 것이 아님!
- 근데 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다. 분명 다형성을 사용했지만 OCP 원칙을 지킬 수 없다. 따라서 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.
LSP: 리스코프 치환 원칙
- Liskov substitution principle
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
- 단순히 컴파일에 성공하는 것을 넘어서는 이야기
ex) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP 위반, 느리더라도 앞으로 가야 함
ISP: 인터페이스 분리 원칙
- Interface Segregation Principle
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- 자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스로 분리
- 사용자 클라이언트 → 운전자 클라이언트, 정비사 클라이언트로 분리
- 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음
- 인터페이스가 명확해지고, 대체 가능성이 높아진다.
DIP: 의존관계 역전 원칙⭐
- Dependency inversion principle
- 프로그래머는” 추상화에 의존해야지, 구체화에 의존하면 안된다” 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
- 쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
- 앞에서 이야기한 역할에 의존하게 해야 한다는 것과 같다. 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다. 구현체에 의존하게 되면 변경이 아주 어려워진다.
📢해당 글은 김영한님의 스프링 핵심 원리 강좌를 기반으로 작성되었습니다.
