스프링이란?
스프링이라는 단어는 문맥에 따라 스프링 DI 컨테이너 기술, 스프링 프레임워크, 스프링 부트와 스프링 프레임워크 등을 포함한 스프링 생태계로 해석된다.
스프링 생태계
스프링 프레임워크, 스프링 부트, 스프링 데이터, 스프링 세션, 스프링 시큐리티, 스프링 Rest Docs, 스프링 배치, 스프링 클라우드 등 다양한 생태계로 구성되어 있다.
- 스프링 프레임워크, 스프링 부트는 필수다.
스프링 프레임워크
- 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타
- 웹 기술: 스프링 MVC, 스프링 WebFlux
- 데이터 접근 기술: 트랜젝션, JDBC, ORM 지원, XML 지원
- 기술 통합: 캐시, 이메일, 원격접근, 스케줄링
- 테스트: 스프링 기반 테스트 지원
- 언어: 코틀린, 그루비
스프링 부트
최근에는 스프링 부트를 통해 스프링 프레임워크 기술을 편리하게 사용한다.
- 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
- Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨
- 손쉬운 빌드 구성을 위한 starter 종속성 제공
- 스프링과 3rd parth(외부) 라이브러리 자동 구성(외부 라이브러리 버전에 대해 사용자가 고민할 필요 없음)
- 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공(모니터링)
- 간결한 설정(필요한 부분만 커스텀해서 사용)
스프링의 핵심 개념, 컨셉?
- 자바 언어 기반의 프레임워크 ⇒ 객체 지향 언어
- 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
⇒ 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크
좋은 객체 지향 프로그래밍이란?
객체지향은 추상화, 캡슐화, 상속, 다형성을 만족한다는 특징이 있다.
- 객체 지향 프로그램은 컴퓨터 프로그램을 여러 개의 독립된 단위, 객체들의 모임으로 파악하고자 한다. 각각의 객체는 협력하여 메시지를 주고받고, 데이터를 처리할 수 있다.
- 프로그램을 유연하고 변경이 용이하게 만들어, 대규모 소프트웨어 개발에 많이 사용된다.
다형성(Polymorphism)이란?
역할과 구현이라는 개념으로 볼 때, 역할과 구현으로 구분하면 대체 가능성이 생겨 유연해지고 변경도 편리해진다. 실세계에서 비유하자면 공연, 키보드와 마우스 같은 표준 인터페이스들, 정렬 알고리즘, 할인 정책 로직 등이 있다.
- 객체를 설계할 때 역할과 구현을 분리해서 설계하는 것이 중요하다!
- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
자바 언어에서 다형성을 적용하여, 역할과 구현을 분리하면 다음과 같다.
- 역할 = 인터페이스
- 구현 = 인터페이스를 구현한 클래스, 구현 객체
자바 언어의 다형성
- 오버라이딩을 떠올리자!
- 오버라이딩된 메서드가 실행된다.
- 다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경할 수 있다.
- 클래스 상속 관계도 다형성, 오버라이딩이 적용 가능하다.
객체를 설계할 때는 역할(인터페이스)을 먼저 부여하고, 역할을 수행하는 구현 객체를 생성한다.
User 정보를 저장하려고 하는데, 아직 어떤 데이터베이스를 사용할지 모르기 때문에 Memory에 저장하도록 하겠다.
그렇다면 아래와 같이 작성할 수 있다.
public class MemberService {
private MemberRepository memberRepository = new MemoryMemberRepository();
}
후에 저장소가 결정되면 교체하면 된다.
public class MemberService {
private MemberRepository memberRepository = new DBMemberRepository();
}
인터페이스를 구현하는 객체 인터페이스는 실행 시점에 유연하게 변경될 수 있다. 즉, 클라이언트는 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.
다형성을 고려하면 유연하고 확장 가능한 설계를 할 수 있으며, 클라이언트에 영항을 주지 않고도 변경할 수 있다.
한계점 ⇒ 역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생한다. 따라서 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.
좋은 객체 지향 설계의 5가지 원리(SOLID)
- SRP: 단일 책임 원칙(single responsibility principle)
- OCP: 개방-폐쇄 원칙(Open/closed principle)
- LSP: 리스코프 치환 원칙(Liskov substitution principle)
- ISP: 인터페이스 분리 원칙(Interface segregation principle)
- DIP: 의존관계 역전 원칙(Dependency inversion principle)
SRP(Single responsibility principle): 단일 책임 원칙
하나의 클래스는 하나의 책임만 갖는다. 변경 시 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다. 책임의 크기는 문맥과 상황에 따라 다르다.
OCP(Open/closed principle): 개방-폐쇄 원칙
소프트웨어 요소는 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다.
다형성을 떠올려서, 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현하는 경우를 생각해보자.
하지만 이 경우 문제점이 있는데, 다형성은 사용했지만 클라이언트 코드가 함께 변경되었기 때문에 OCP 원칙을 지킬 수 없다. 따라서 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.
LSP(Liskov substitution principle): 리스코프 치환 원칙
프로그램의 객체는 프로그램 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 컴파일에 성공하는 것을 넘어서 기능적으로 보장해줘야 한다. (ex. enter를 누르면 다음 줄로 넘어가야 한다.)
ISP(Interface segregation principle): 인터페이스 분리 원칙
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- 통장 인터페이스 -> 출금 인터페이스, 예금 인터페이스
- 사용자 인터페이스 -> 직원 클라이언트, 고객 클라이언트
분리하면 특정 인터페이스가 변해도, 다른 클라이언트에 영향을 주지 않아 인터페이스가 명확해지고, 대체 가능성이 높아진다.
DIP(Dependency inversion principle): DIP 의존관계 역전 원칙
"추상화에 의존해야지, 구체화에 의존하면 안된다." 는 말은 구현 클래스에 의존하지 말고, 인터페이스에 의존해야 한다는 말이다. 즉 역할(Role)에 의존해야 한다.
UserRepository user = new DBUserRepository(); 는 클라이언트가 구현 클래스를 직접 선택했기 때문에 DIP를 위반한 경우다.
모든 설계에 역할과 구현을 분리해야 한다. 구현 대상은 언제든지 변경할 수 있도록 유연하게 설계해야 한다. 하지만 인터페이스를 도입하면 추상화라는 비용이 발생한다. 따라서 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고 추후 리팩토링해서 인터페이스를 도입해라.
