스프링 핵심 원리 기본편 강의 - 스프링

스프링이란?

• Spring framework / Spring boot 필수
• Spring batch, Spring Session, Spring Data 등등

스프링프레임워크

• 핵심기술
• 웹기술
• 데이터 접근 기술
• 기술 통합
• 테스트
• 언어

스프링 부트

• 최근에 기본으로 사용
• Spring Application을 쉽게 생성
• 내장 톰캣 지원
• 손쉬운 빌드 구성을 위한 starter 종속성 제공
• 프로덕션 준비 기능 제공
• 간결한 설정

스프링 부트만 사용 할 수 없고, 실제는 스프링 프레임워크를 사용한다.

스프링이란 단어?

• 스프링 생태계
• 스프링 프레임워크
• 스프링 DI 컨테이너 기술

스프링 진짜 핵심

• 자바 언어 - 객체 지향 언어
• 스프링은 객체 지향 언어가 가진 강력한 특징으로 개발 할 수 있도록 돕는 프레임워크

다형성 / 객체

• 역할과 구현으로 구분하는 것에 초점을 맞추면 됨.
• 유연한 구조를 가지게 함.
  • 클라이언트는 대상의 역할만 알면 된다.
  • 클라이언트는 구현 대상의 내부 구조 몰라도 된다.
  • 클라이언트는 구현 대상의 내부 구조가 변경 되어도 영향이 없다.
  • 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
• 객체를 설계 할 때 역할과 구현을 명확히 분리
• 객체는 협력이라는 관계부터 생각 하라.
  • 혼자 있는 객체는 없다.
  • 클라이언트: 요청, 서버: 응답
  • 수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다.

다형성의 본질

• 인터페이스를 구현한 객체 인스턴스 실행 시점에 유연하게 변경할 수 있다.
• 협력이라는 객체 사이의 관계에서 시작해야 함.
• 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

SOLID

• SRP 단일 책임 원칙
• OCP 개방-폐쇄 원칙
• LSP 리스코프 치환 원칙
• ISP 인터페이스 분리 원칙
• DIP 의존관계 역전 원칙

SRP (Single Responsibility princicple)

• 한 클래스는 하나의 책임만 가져야 한다.
• 하나의 책임은 모호함.
• 중요한 기준은 변경이다.
  • 변경을 할 때, 파급 효과가 적으면 해당 원칙을 잘 지킨 것

OCP (Open/Closed princicple)

• 확장에는 열려 있고, 변경에는 닫혀있다.
• 다형성을 활용해야 함.
• 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현
• 구현 객체를 바꾸면, 클라이언트 코드를 변경 해야 한다. => OCP가 깨진다.
  • 역할과 구현의 분리를 적용
    • 객체 생성과 연결 해주는 설정 매개체가 있어야 함. => 이걸 스프링 컨테이너가 해준다.

LSP (Liskov substitution princicple)

• 프로그램의 객체는 프로그램의 정확성을 꺠뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다.

ISP (Interface segregation princicple)

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
• 인터페이스가 명확해지고, 대체 가능성이 높아진다.

DIP (Dependency inversion princicple)

• 구현 클래스에 의존하지 말고, 인터페이스에 의존해야 함.
  • 추상화에 의존하고, 구체화에 의존하지 말자.
  • 결국, 역할에 의존 하게끔 해야지, 구현체를 바라보면 안 됨.
    • 이 말은 결국, 스프링에서 빈을 외부에서 주입 해주려고 하는 이유..근데, 생각해보면 어떻게 그렇게 큰 프로젝트에서 원칙들을 다 지키는 걸까? 대단하다..

객체지향 설계와 스프링

• 스프링은 다형성 + OCP, DIP를 지키기 위해서 DI 컨테이너를 지원 함.
• 스프링 없을 때는, EJB 시절이라 객체 지향은 개뿔 코드를 깔끔하게 작성 하기도 어려움.
  • 로드 존슨이 책에서 만든 예제를 천재 개발자들이 모여서 오픈 소스로 구성 제안
• 거의 모든 설계에 인터페이스를 넣는게 이상적이다.

실무 고민

• 인터페이스를 도입 하면 추상화 비용이 발생
• 기능을 확장 할 가능성이 없으면, 그냥 사용하고 그게 아니면 리팩토링 하면서 인터페이스를 만들어주는게 좋다.

---

• 생각보다 많은 내용을 정말 빠른 시간내에 설명을 하시는데, 그 설명이 어렵지도 않다.
• 내가 이 강의를 듣게 된 이유는 단 하나, 코드 예제를 보고 싶어서다. (기대가 된다.)
• 어떻게 보면, 아키텍트의 관점일 수 있는데, 경험이 결국 중요한데, 그냥 경험이 아니라 좋은 경험이 많이 쌓여야 한다. 결과적으로 개발 짬은 그냥 쌓이는 게 아니다.