Spring (1)

0. 지극히 개인적인 정리

 

1. 연대기

 1) EJB (Enterprise Java Bean)

  (1) 빵빵한 고급 기술 지원 -> 기술 종합 세트 -> 어렵고 복잡하고 속도 느림(컨테이너 하나 올리는데 세월아 네월아)

  (2) 비싼 가격으로 인한 비용 부담

  (3) interface를 다 구현해야 하고 EJB에 의존적으로 개발할 수밖에 없음

 

 2) POJO(Plain Old Java Object)

  (1) 차라리 원시 자바 오브젝트로 회귀하자는 운동

  (2) 덩달아 그동안 무시됐던 open source 시장의 확장 및 성장

 

 3) Spring (과거의 어두웠던 Java 생태계에 봄이 도래)

  (1) 2002년 EJB를 버리고도 고품질의 확장이 가능한 애플리케이션 개발이 가능함을 로드 존슨이 증명

  (2) 유겐 휠러, 얀 카로프, 로드 존슨이 EJB의 겨울을 넘어 새로운 시작, 봄이 왔음을 선언

  (3) 설정과 세팅에 많은 시간이 소요 -> 설정과 세팅이 spring의 절반이라는 말이 있을 정도

  (4) hibernate (EJB의 entity bean 대체)

  (5) JPA가 새로운 표준을 제시 및 정의

  (6) 기존 spring의 설정 및 세팅의 어려움을 극복, 개선한 spring boot가 2014년 등장

 

2. 콘셉트

 1) framework: 어떠한 문제점을 쉽게 해결하기 위해 예시 및 작업물들이 포함된 틀

 2) 객체지향 언어인 Java 기반의 개발을 돕는 framework

 3) 다형성(polymorphism)

  (1) 운전자는 자동차 면허와 키를 쥐고 있으면 자동차의 종류는 다양하지만, 어떠한 자동차라도 운전할 수 있음

  (2) 운전자는 자동차 내부의 세세한 작동방식 및 기술, 구조를 굳이 알 필요가 없음 (encapsulation)

  (3) (1), (2)에서 보듯 유연하고 변경이 용이 = 객체지향 개발의 장점

 4) interface의 중요성이 그만큼 상승 -> interface가 변경되면 다형성을 통해 구현된 것들이 의미가 없어짐

 5) spring container = spring에서 다형성을 사용하기 쉽게 지원하는 역할

 

3. SOLID: 좋은 객체지향 설계의 5원칙으로 클린코드 제창자(로버트 C 마틴)가 제시

 1) 단일 책임 원칙(SRP): 한 클래스는 하나의 책임만 가짐

 2) 개방 폐쇄 원칙(OCP): 소프트웨어는 확장에는 열려있지만, 변경에는 닫혀있어야 함

 3) 리스코프 치환원칙(LSP): 프로그램의 정확성을 깨지않고 하위 타입의 instance를 바꿀 수 있어야 함

 4) 인터페이스 분리원칙(ISP): 특정 클라이언트를 위한 interface 여러개가 범용 interface 1개보다 나음

 5) 의존관계 역전원칙(DIP): 추상화(generalization)에 의존해야지, 구체화(specialization)에 의존하면 안됨

 

4. IoC(Inversion of Control)

 1) 내가 프로그램을 직접 호출하는 것이 아니라, framework 같은 것이 호출하는 것

 2) 프로그램의 제어 흐름을 직접 담당하지 않고, 외부에서 흐름을 담당하는 것

 

 ※ framework vs library

  (1) 내가 작성한 코드를 대신 실행하고 제어하면 framework

  (2) 내가 작성한 코드를 직접 제어하고 실행하고 담당하면 library

 

5. DI(Dependency Injection)

 1) 정적인 클래스 의존관계

  (1) import 코드만 보고도 의존관계를 쉽게 판단할 수 있음

  (2) 애플리케이션을 실행하지 않고도 분석이 가능

  (3) 클래스 다이어그램으로도 관계 파악 가능

 

 2) 동적인 인스턴스 의존관계

  (1) 애플리케이션 실행시점에 의존이 결정

  (2) 클라이언트와 서버의 실제 의존관계가 연결될 때 확인 가능

 

6. IoC container, DI container: 객체를 생성하고 의존관계를 연결하는 창고