- 핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타
- 웹 기술 : 스프링 MVC, 스프링 WebFlux
- 데이터 접근 기술 : 트랜잭션, JDBC, ORM, XML 지원
- 기술 통합 : 캐시, 이메일, 원격접근, 스케줄링
- 테스트 : 스프링 기반 테스트 지원
- 언어 : 코틀린, 그루비
- 스프링을 편리하게 사용할 수 있도록 지원 (최근에는 기본으로 사용)
- Tomcat같은 웹 서버를 내장하여 별도의 웹 서버를 설치하지 않아도 됨
- 스프링과 외부 라이브러리 자동 구성 (버전에 신경쓰지 않아도 알아서 맞춰준다)
- 손쉬운 빌드 구성을 위한 starter 종속성 제공
- 자바 언어 기반의 프레임워크
- 자바 언어의 가장 큰 특징 - 객체 지향 언어
- 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
- 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크
- 객체 지향 프로그래밍은 컴퓨터 프로그램을 단순히 명령어들이 아닌 여러개의 독립된 단위인 “객체”들의 모임으로 파악하는 것이다. 각각의 객체는 메세지를 주고받고 데이터를 처리하여 협력한다.
- 객체 지향 프로그래밍은 프로그램을 “유연하고 변경이 용이하게 만들”기 때문에 대규모 소프트웨어 개발에 많이 사용된다.
- 유연하고 변경이 용이하다 == 레고 블럭을 조립하듯이 == 다형성
- 역할과 구현으로 나눈다
예 ) 자동차와 운전자
- 운전자의 역할은 자동차를 운전하는 것이다.
- 자동차의 역할은 운전자를 태워 이동하는 것이다.
- 자동차의 구현이 k3이든, 아반떼이든, 테슬라이든 자동차의 역할을 할 수 있다
- 운전자가 누구든 역할을 할 수 있다.
- 새로운 자동차가 생겨도 자동차의 역할을 수행한다면 (인터페이스에 맞게 구현되어 있다면) 운전자는 별도로 공부할 필요 없이 운전할 수 있다.
예 ) 공연 무대
-
로미오와 줄리엣의 역할을 다른 배우가 대체할 수 있다.
-
역할과 구현으로 구분하면 세상이 단순해지고 유연해지며 변경도 편리해진다.
-
장점
- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
자바 언어의 다형성을 활용
- 역할 = 인터페이스
- 구현 = 인터페이스를 구현한 클래스 , 구현 객체
- 객체를 설계할 때 역할과 구현을 명확히 분리
- 객체 설계 시 역할(인터페이스)을 먼저 부여하고 그 역할을 수행하는 구현 객체 만들기
다형성의 본질
- 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경 가능하다.
- 다형성의 본질을 이해하려면 협력이라는 객체사이의 관계에서 시작해야함
- 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.
→ 인터페이스를 안정적으로 잘 설계하는 것이 중요
역할과 구현을 분리의 단점
- 역할 자체가 변하면 큰 변경이 발생
- 다형성이 가장 중요하다
- 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다
- 제어의 역전(IoC), 의존관계 주입(DI)가 다형성을 활용하여 역할과 구현을 편리하게 다루도록 지원한다.
- 스프링을 사용하면 마치 레고 블럭을 조립하듯이! 공연 무대의 배우를 선택하듯이! 구현을 편리하게 변경할 수 있다.
좋은 객체 지향설계의 5가지 원칙을 정리
SRP (Single responsibility principle) 단일 책임 원칙
- 한 클래스는 하나의 책임만 가져야 한다.
- 하나의 책임이란 모호하다
- 클수도 있고 작을 수도 있다.
- 문맥과 상황에 따라 다르다
- 중요한 기준은 “변경”이다. 변경이 있을 때 파급 효과가 적으면 SRP를 잘 따른 것
- ex : 객체의 생성과 사용을 분리
OCP (Open/closed principle) 개방-폐쇄 원칙
- 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야 한다.
- 그러나 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다
LSP (Liskov substitution principle) 리스코프 치환 원칙
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 하는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체를 믿고 사용하려면 이 원칙이 필요
- 단순히 컴파일 성공이 아닌 구현체가 해당 역할을 잘 수행해야 하는 것
ISP (Interface segregation principle) 인터페이스 분리 원칙
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나 보다 낫다
- 자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스로 분리
- 사용자 인터페이스 → 운전자 인터페이스, 정비사 인터페이스로 분리
- 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음
- 인터페이스가 명확해지고 대체 가능성이 높아진다.
DIP (Dependency inversion principle) 의존관계 역전 원칙
- 프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다” 의존성 주입은 이 원칙을 따르는 방법 중 하나이다.
- 구현 클래스에 의존하지 말고 인터페이스에 의존하라는 뜻
- 역할에 의존하게 해야 한다는 것과 같다. 역할에 의존하지 않고 구현체에 의존한다면 변경이 어려워 진다.
다형성 만으로 OCP와 DIP를 지킬 수 없다.
다형성으로 역할과 구현을 나눠도 결국 구현 객체를 변경할 때 코드도 변경된다.
클라이언트가 구현체를 바꿀 때
서비스 = 자동차.k3
⇒ 서비스 = 자동차.테슬라
- 스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원
- DI(Dependency Injection) : 의존관계, 의존성 주입
- DI 컨테이너 제공
- 클라이언트 코드의 변경 없이 기능 확장
- 쉽게 부품을 교체하듯이 개발
- 모든 설계에 역할과 구현을 분리
- 애플리케이션 설계도 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계이다.
- 이상적으로는 모든 설계에 인터페이스를 부여하자.