스프링 핵심 원리 - 기본편 [Section 1. 객체 지향 설계와 스프링]

스프링 역사

• 개발자 로드 존슨 → EJB 의 문제점 지적, 책 출판
• 유겐 휠러, 얀 카로프가 로드 존슨에게 오픈소스 프로젝트 제안

 

스프링이란?

스프링 생태계

• 필수
  • 스프링 프레임워크, 스프링 부트
• 선택
  • 스프링 데이터, 스프링 세션, 스프링 시큐리티, 스프링 Rest Docs, 스프링 배치, 스프링 클라우드

 

스프링 프레임워크

• 핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타

 

스프링 부트

• 스프링을 편리하게 사용할 수 있게 지원
• 톰캣 같은 웹 서버 내장 → 별도의 웹 서버 설치 불필요
• 버전을 지정해서 다운로드 하게 해줌
• 메트릭/상태 확인/외부 구성 같은 프로덕션 준비 기능 제공
• 스프링과 별도로 사용할 수 있는 게 아님

 

스프링이라는 단어

• 문맥에 따라!
  • 스프링 DI 컨테이너 기술
  • 스프링 프레임워크
  • 스프링 부트, 스프링 프레임워크 등 포함 스프링 생태계

 

스프링 왜 만들었나?

스프링의 핵심 개념

• 자바 언어 기반 프레임워크
• 자바 → 객체 지향 언어
• 객체 지향 언어가 가진 강력한 특징 살려내는 프레임워크
• 좋은 객체 지향 애플리케이션 개발을 도와주는 프레임워크

 

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

객체 지향 프로그래밍?

• 객체들의 모임
• 객체들은 서로 메시지를 주고받을 수 있음
• 유연, 변경이 용이

 

유연, 변경이 용이?

→ 객체 지향의 핵심 : 다형성

 

 

다형성의 실세계 비유

• 실세계와 객체 지향을 1:1로 매칭

(예시1)
자동차가 바뀌어도 운전자는 운전 할 수 있음
→ 테슬라를 산다고 해서 다른 운전면허를 따야하는 게 아님

운전자는 자동차 역할 (인터페이스)에만 의존
다른 대상으로 변환 가능. 기존의 자동차 역할 그대로 따라갈 수 있음
자동차를 무한 확장 가능
→ 새로운 자동차가 나와도, 클라이언트는 새로운 걸 배우지 않아도 됨

 

(예시2)
로미오 역할 : 장동건, 원빈 등 남자 배우
줄리엣 역할 : 김태희, 송혜교 등의 여자 배우 모두 가능!
→ 줄리엣의 구현이 바뀐다고 해서 로미오에게 영향 미치지 않음

 

 

역할과 구현을 분리

• 역할과 구현으로 구분하면 세상이 단순해지고, 유연해짐. 변경도 편리해짐
• 장점
  • 클라이언트는 대상의 역할(인터페이스)만 알면 됨
  • 클라이언트는 구현 대상의 내부 구조를 몰라도 됨
  • 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향 받지 X
  • 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않음

 

in 자바 언어

→ 자바 언어의 다형성을 활용!

• 역할은 인터페이스
• 구현은 인터페이스를 구현하는 객체. (구현 객체)
• 객체 설계할 때 역할/구현 명확히 분리!
• 객체 설계시 역할 먼저 부여, 그 역할 수행하는 구현 객체 만들자

---

객체의 협력이라는 관계부터 생각

• 혼자 있는 객체는 없음
• 클라이언트 : 요청
• 서버 : 응답
• 수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계

클라이언트 → MemberRepository 에 의존 (의존 : 알고있다는 뜻임)

 

다형성의 본질

• 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경 가능
• 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있음

 

인터페이스를 안정적으로 설계하는 것이 가장 중요함

스프링과 객체 지향

• 다형성이 가장 중요
• 스프링은 다형성을 극대화해 이용할 수 있게 도와줌
• 제어의 역전, 의존관계 주입 → 다형성 활용, 역할과 구현 편리하게 다룰 수 있도록 지원함

---

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

SRP (단일 책임 원칙)

하나의 클래스는 하나의 책임만 가지자.

• 하나의 책임이 뭐임 ? 모호하자나여!
  • 클 수도 있고 작을 수도 있고..
  • 문맥/상황에 따라 다름
• 중요한 기준은 변경! → 변경 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것임

OCP (개방-폐쇄 원칙)****

소프트웨어 요소는 확장에는 열려 있으나, 변경에는 닫혀 있어야 함!

(머선 말인데?)

• 다형성을 활용해보자
  • 그니까 자동차-운전자의 개념에서
  • 인터페이스를 하나 더 만드는 거는 기존 코드를 변경하는 게 아님(확장)
• 문제점
  • 구현 객체를 변경하려면 클라이언트 코드를 변경해야 함..
  • 분명 다형성 사용했는데도 OCP 지킬 수 없게 됨
  • 객체 생성/연관관계 맺어주는 별도의 조립, 설정자가 필요!

LSP (리스코프 치환 원칙)

프로그램의 객체는 프로그램의 정확성을 깨지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 함!

ISP (인터페이스 분리 원칙)

• 특정 클라이언트 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다

DIP (의존관계 역전 원칙)****

• 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안 됨
• 즉, 구현 클래스보다 인터페이스에 의존하라는 뜻
• DIP 위반 
  • OCP에서 설명한 MemberService는 인터페이스에 의존하지만 구현 클래스도 동시에 의존함
  • MemberService 클라이언트가 구현 클래스를 직접 선택

MemberRepository m = new MemoryMemberRepository();

---

객체 지향 설계와 스프링

• 스프링은 다음 기술로 다형성 + OCP, DIP 가능하게 지원해주는 기술
  • DI : 의존관계/의존성 주입
  • DI 컨테이너 제공
• 클라이언트 코드 변경 없이 기능 확장

정리

• 모든 설계에 역할과 구현을 분리하자
• 이상적 → 모든 설계에 인터페이스를 부여하자