스프링 핵심 원리 - 기본편 (1)

<스프링 핵심 원리 - 기본편>

• 인프런 김영한님 강의 필기

객체 지향 설계와 스프링

1. 이야기 - 자바 진영의 추운 겨울과 스프링의 탄생
2. 스프링이란?
3. 좋은 객체 지향 프로그래밍이란?
4. 좋은 객체 지향 설계의 5가지 원칙(SOLID)
5. 객체 지향 설계와 스프링

1. 이야기 - 자바 진영의 추운 겨울과 스프링의 탄생

• 2000년대 초반 자바당 정파 기술 - EJB (Enterprise Java Beans)
• 당시 오픈소스는 사파 기술.. 기존 시스템에 새로 도입하기에 리스크가 있었음
• 그러나 EJB는 굉장히 복잡하고 의존적으로 코딩하게 되어 객체지향 설계의 장점을 잃어버림
• 2002년 로드 존슨이 30000줄짜리 스프링 시초 코드 들어있는 책 출간
• 유겐 휠러, 얀 카로프 등 사람들이 로드 존슨 찾아가서 오픈소스 프로젝트 제안

스프링 역사

• 2003년 스프링 프레임워크 1.0 - XML
• 2006년 스프링 프레임워크 2.0 - XML 편의기능 지원
• 2009년 스프링 프레임워크 3.0 - 자바 코드로 설정
• 2013년 스프링 프레임워크 4.0 - 자바8
• 2014년 스프링 부트 1.0
• 2017년 스프링 프레임워크 5.0, 스프링 부트 2.0 - 리엑티브 프로그래밍 지원
• 2022년 현재 버전 업그레이드 진행중..

2. 스프링이란?

• 스프링은 자바 기반의 오픈 소스 프레임워크
• 웹 어플리케이션을 만들기 위한 여러 가지 기능을 제공

스프링 프레임워크

• 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타
• 웹 기술: 스프링 MVC, 스프링 WebFlux
• 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원
• 기술 통합: 캐시, 이메일, 원격접근, 스케줄링
• 테스트: 스프링 기반 테스트 지원
• 언어: 자바, 코틀린, 그루비 지원
• +) 최근에는 스프링 부트를 통해서 스프링 프레임워크 기술들을 편리하게 사용중

스프링 부트

• 스프링 프레임워크를 편리하게 사용할 수 있도록 지원, 최근에는 디폴트로 사용
• 단독으로 실행 가능한 스프링 애플리케이션을 쉽게 생성
• Tomcat 같은 웹 서버를 내장해서 별도로 웹 서버를 설치하지 않아도 됨
• 손쉬운 빌드 구성을 위한 starter 종속성 제공
• 스프링과 3rd party(외부) 라이브러리 자동 구성
• 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
• 관례에 의한 간결한 설정

스프링 진짜 핵심 ★★★★★

• 스프링은 자바 언어가 가진 객체 지향적 특징을 가장 잘 활용할 수 있게 도와주는 프레임워크
• 스프링을 통해 좋은 객체 지향 어플리케이션을 개발할 수 있다.

3. 좋은 객체 지향 프로그래밍이란?

객체 지향 프로그래밍

• 프로그램이 독립된 객체들의 조합이라는 개념을 도입하여 프로그래밍하는 방법론
• 각각의 객체는 메시지를 주고받으며 데이터 처리에 협력 가능
• 프로그램 구조 변경이 쉬워져 대규모 소프트웨어 개발에 많이 사용
• 객체 지향 특징 - 캡, 추, 상, 다

다형성

• 역할 / 구현으로 세상을 구분
• 역할이 정해지면 누가 구현체로 들어오든 문제 없음, ex) 운전자-자동차, 로미오-줄리엣

자바 언어의 다형성

• 역할 = 인터페이스
• 구현 = 인터페이스를 구현한 클래스
• 객체 설계 시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 객체 만들기
• 오버라이딩 - 부모 클래스의 메서드를 자식 클래스에서 재정의 가능
• 다형성으로 인터페이스 구현한 객체를 실행 시점에 변경 가능, 오버라이딩 메서드 사용
• 즉, 클라이언트 변경 없이 서버의 구현 기능을 유연하게 변경 가능

스프링과 객체 지향

• 다형성이 가장 중요
• 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다.
• 스프링의 IoC, DI 는 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.

4. 좋은 객체 지향 설계의 5가지 원칙 (SOLID)

• SOLID - 클린 코드를 위한 5가지 설계 원칙
• SRP, OCP, LSP, ISP, DIP

(1) SRP 단일 책임 원칙 (Single Responsibility Principle)

• 한 클래스는 하나의 책임만 가져야 한다.
• 클래스 변경이 있을 때 파급효과가 적을수록 잘 지켜진 것

(2) OCP 개방 폐쇄 원칙 (Open Closed Principle)

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 인터페이스에 구현체를 계속 추가하는 구조로 기존 코드 변경 없이 확장 가능
• ex) 서비스가 리포지토리 구현 클래스 직접 선택 시, 코드 변경이 발생하므로 OCP 위반
  -> 객체를 생성하고 연관관계를 맺어주는 별도의 설정자 필요 (Spring)

public class MemberService {

	// MemberRepository m = new MemoryMemberRepository(); // 기존 코드
	MemberRepository m = new JdbcMemberRepository();      // 변경 코드

}

(3) LSP 리스코프 치환 법칙 (Liskov Substitution Principle)

• 구현체는 인터페이스의 규약을 깨뜨리지 않아야 한다.
• ex) 자동차 인터페이스에서 엑셀은 앞으로 가는 기능, 뒤로 가게 구현하면 LSP 위반

(4) ISP 인터페이스 분리 원칙 (Interface Segregation Principle)

• 특정 클라이언트를 위한 인터페이스 여러 개가 하나의 범용 인터페이스보다 낫다.
• 자동차 인터페이스 - 운전, 정비로 나누면
• 사용자 인터페이스 - 운전자, 정비사로 나눌 수 있음
• 인터페이스가 변해도 구현체에 영향을 주지않으므로 인터페이스 대체가 더 용이해짐

(5) DIP 의존관계 역전 원칙 (Dependency Inversion Principle)

• 구현 클래스(구현체)에 의존하지 말고 인터페이스에 의존해야 한다.
• ex) 운전자 클라이언트는 자동차 구현체 아반떼, k3에 상관없이 자동차 인터페이스 사용 가능하다.
• ex) 서비스가 리포지토리 구현 클래스 직접 선택 시, 구현체에 의존하게 되므로 DIP 위반

public class MemberService {

	// MemberRepository m = new MemoryMemberRepository();
	MemberRepository m = new JdbcMemberRepository();    
    // 코드 그냥 사용만 해도 바뀔 때 영향받으므로 의존 관계임

}

객체 지향 설계 원칙 정리

• 객체 지향의 핵심은 다형성
• 다형성을 이용해 인터페이스와 구현체 만들었지만, 구현체 변경 시 클라이언트 코드도 함께 변경된다.
• OCP, DIP를 지키기 위해서 별도의 설정자가 필요하다.

5. 객체 지향 설계와 스프링

스프링 DI, DI 컨테이너

• 스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원
  • DI - 의존관계, 의존성 주입
  • DI 컨테이너 제공
• 클라이언트 코드의 변경 없이 기능 확장 가능
• 애플리케이션 설계도 공연을 설계하듯이 배역만 만들어두고 배우는 언제든지 변경할 수 있도록 만드는 것이 좋은 객체지향 설계
• 이상적으로는 모든 설계에 인터페이스를 부여하자.

실무 고민

• 모든 곳에 인터페이스를 도입하면 베스트지만, 이것도 하나하나 일이 됨
• 기능 확장 가능성이 없다면 일단 구현 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩터링해서 인터페이스 도입하는 것도 방법

책 추천

• 객체지향 책 - 객체지향의 사실과 오해
• 스프링 책 - 토비의 스프링
• JPA 책 - 자바 ORM 표준 JPA 프로그래밍