What is Spring?
자바를 기반으로 만들어진 프레임 워크. 자바의 복잡한 EJB의 의존적인 환경을 벗어나서, Saclabe하고 OOP의 개념을 적극적으로 활용한 프레임 워크이다.
Origin of Spring
태초에 EJB가 있었다. 비싸고 무겁고, 굉장히 의존적인 코드를 작성해야 하는 EJB는 많은 개발자들에게 문제점으로 지적이 되었다. 그에 따른 불만을 품고 두 개발자가 Spring과 Hibernate를 만들고, JAVA의 세계에 Spring(봄)이 오게 된다.
너무 크고 무거운 EJB는 말 그대로 ‘JAVA 더 헛’이다.
로드 존슨
EJB 없이도 충분히 고품질의 확장 가능한 애플리케이션을 개발할 수 있음을 보여줬다(Spring의 전신)
(BeanFactory, ApplicationContext, POJO, IoC, DI)
OOP (Object Oriented Programming)
객체 지향 프로그래밍, 프로그래밍을 ‘객체'라는 개념으로 묶어서, 각각의 객체들이 상호간의 소통하며 프로그램이 동작하는 것을 생각하는 패러다임
역할과 구현을 구분하라
역할과 구현을 구분하라는 뜻은 무엇일까? 각 객체 내에서 일어나는 일은 객체 내에서만 일어나고, 각각의 객체가 다른객체가 맡고 있는 역할에 의존적이지 않은 형태를 뜻한다.
운전자는 운전자의 역할이 있고 자동차는 자동차의 역할이 있다. 운전자는 자동차가 기름으로 가던, 전기로 가던 신경 쓰지 않고, 도로에서 운전을 할 수 있다. 또한 자동차는 자동차의 역할을 바탕으로 다양한 자동차 모델들이 구현될 수 있다.
SOLID (객체지향의 5요소)
Single Responsibility Principle 단일 책임의 원칙
- class(=객체)는 하나의 책임(목적, 역할 등)만 지녀야 한다는 원칙이다.
- 새로운 기능을 기존 class에 추가하게 되면, (=하나의 class가 여러 기능을 수행하면)코드가 길어지고 복잡해진다. 또 나중에 수정해야할 때 시간이 많이 걸릴 수 있다.
Open/Closed Principle 개방/폐쇄의 원칙
- class(=객체, 함수 등)는 확장에는 개방 되어야하나, 수정에는 폐쇄 되어야한다.(Class should be open for extension, but closed for modification.)
- 부모 class에서 자식 class를 만들 때, 자식 class에서 기능을 추가/수정할 수 있지만,자식 class를 위해 부모 class가 수정될 필요는 없다.
Liskov’s Substitution Principle 리스코프 치환 원칙
- 자식 class는 언제나 자신의 부모 class를 교체할 수 있다는 원칙이다.
- 이 원칙은 1987년 Barbara Liskov가 소개했다.
- 부모 class의 위치에 자식 class로 넣어도 어떠한 issue도 없어야 한다는 원칙이다.
Interface Segregation Principle 인터페이스 분리 원칙
- 클라이언트가 자신과 관련이 없는 인터페이스는 구현하지 않아야 한다.(Do not force any client to implement an interface which is irrelevant to them.)
- class는 자신이 사용하지 않는 method는 구현하지 않아야 한다.
Dependency Inversion Principle 의존성 역전 원칙
- 고차원 module/class는 저차원 module/class에 의존하면 안된다는 원칙이다.(High-level modules/classes should not depend on low-level modules/classes.)(고차원, 저차원 module/Class는 모두 추상화(abstractions)에는 의존한다.)
- 추상화는 세부사항에 의존해서는 안되고, 세부사항은 추상화에 의존해야한다.(Abstractions should not depend upon details. Details should depend upon abstractions.)
POJO Plain Old Java Object
스프링 삼각형
getter setter와 같은 기본적인 기능만 가진 자바 객체를 말한다. Spring은 프레임워크의 거대한 기능들을 implements하는 방식으로 만들어 지지 않고, JAVA의 객체지향에 집중하고, 특정 클래스나 라이브러리에 종속되지 않는 객체들을 통해서 문제점을 해결하려고 한다. 앞으로 나올 AOP나 DI, IoC와 같은 기술들이 모두 POJO를 기반으로 구성되어 있다.
AOP Aspect Oriented Programming
가끔은 다른 클래스들 내부에 같은 관점을 가지고 동작하는 코드가 존재할 수 있다.
AOP는 관점을 중심으로 분리를 하려고 하는 프로그래밍 기법으로, 클래스 내의 같은 기능을 하는 코드를 분리하고 따로 관리하여서 각각의 비즈니스 코드를 분리하여서 생각하려고 하는 개발 기법이다.
이러한 흩어진 관심사를 모아서 재사용하겠다는 취지의 프로그래밍 방식이 AOP이다.
AOP는 프록시 패턴을 사용하여서, 직접적으로 객체가 바로 호출되는 것이 아니라 Spring이 프록시 객체로 바꿔치기를 진행한다.
PSA Portable Service Abstraction
스프링의 서비스들은 Low Level까지 알 필요 없도록 짜여져 있기 때문에, Portable하게 이 곳 저곳에 적용하여서 사용할 수 있다.
그리고…
IoC Inversion of Control
객체를 생성하고, 객체간의 의존 관계를 설정하는 것을, 개발자가 아니라 스프링이 직접 관리하는 것을, 제어권을 개발자에서 외부의 컨테이너에게 주었기 때문에 IoC, 제어의 역전이라고 한다.
Spring은 Bean Container에서 Bean에 등록할 객체를 찾아서, 그 객체가 필요한 순간에 주입하게 된다.
DI (Dependency Injection)
