😵 목적
각각의 개념들을 정리한 포스트들은 있지만, 한번에 보기 난해하고 전체적인 흐름을 잡기 위해
스프링의 3가지 핵심 프로그래밍 모델을 정리하려고한다.
전체적으로 개념에 대한 내용이므로 세부적인 사항은 생략되는 부분이 있을 수 있다.
✔️ 들어가기전 전체적 흐름
들어가기전 정리하고자하는 스프링에는 3가지 핵심 프로그래밍 모델은 아래와 같다.
첫번째 IoC/DI라고 불리는 오브젝트의 생명주기와 의존관계에 대한 프로그래밍 모델이다.
두번째 특정환경이나 기술에 종속되어 있지 않고 이식성이 뛰어는 서비스 추상화이다.
세번째 관점지향프로그래밍인 AOP이다.
이 3가지를 개별적으로 정리한적은 있지만, 전체적인 관점으로 묶어 알아보고 정리해보려고한다.
첫번째 🧐 IoC/DI
스프링 시리즈에서 정리한 바가 있다. 참고사항
다시 한번 각각의 뜻과 기능을 정리해보자
IoC란?
Inversion of Control의 줄임말로 한글로 번역하면 제어의 역전 이라는 말이다
말그대로 메소드나 객체의 호출작업을 개발자가 결정하는 것이 아닌 외부에서 결정되는 것을 의미한다.
즉, 스프링 컨테이너가 필요에 따라 개발자 대신 Bean들을 제어 해주는 행위이다.
(여기서 말하는 Bean의 제어: 빈의 생성과 의존 관계설정, 사용, 제거,등)
이 내용은 프레임워크와 라이브러리의 차이점이기도 하다
프레임워크는 자체적인 흐름을 가지고 있어 사용자로 하여금 코드를 연결할 공간을 강제하지만 라이브러리는 사용자에게 흐름을 제어하도록 한다
여기서 질문, 프레임워크와 라이브러리의 차이점과 제어의 "역전"을 생각하다 보면 위에서 말했듯이 프레임워크는 자체적인 흐름을 강제하게되는 것에 역전이라고 생각한다면, "개발자가 직접 프레임워크를 제어하는건가?" 라고 질문할 수 있다.
위에 대한 질문은 틀린 답이다. 그 이유는 IoC는 위에서 설명했듯 개발자를 제외한 외부에서 제어해주는 행위 자체를 제어의 역전이라고 칭하는 것이다. 또한 "제어" 라는 주어의 반대를 칭하는 것이지, 프레임워크의 흐름을 반대로 생각하면 안된다는 것이다.
그렇다면 DI는?
Dependency Injection의 약자로 의존성 주입이라는 기법이다.
여기서의 의존성이란 한 객체가 다른 객체를 사용할때 의존성이 있다고 한다. ("의존하다"라는 의미로 보면된다)
외부에서 두 객체 간의 관계를 결정해주는 디자인 패턴으로, 인터페이스를 사이에 둬서 클래스 레벨에서는 의존관계가 고정되지 않도록하고 런타임 시에 관계를 주입하여 유연성을 확보하고 결합도를 낮출 수 있도록 해준다
사용이유는 높은 응집성과 낮은 결합도를 위해서다
이를 통해 따라오는 장점에는 관심사의 분리와 테스트 작성의 용이함이 있다
이것은 토비의 스프링에서도 언급되었지만, 개방폐쇄의 원칙(OCP)를 지키기 위함이다
이 부분은 객체지향의 5원칙(SOLID)에서 따로 정리하겠다.
왜 IoC는 DI 와 붙어다닐까?
처음 IoC/DI를 공부할 때 생긴 단순 호기심이었다 분명 다들 스프링의 핵심 프로그래밍 모델 3가지라고 기술했는데 IoC/DI는 합쳐서 한가지로 분류하는 걸까?
여기서부터 주관적 생각이 많이 포함될 것이다.
(참고자료들이 많지 않아서 추측하는 부분도 분명히 존재)
- 제어의역전(IoC)에서의 개념인 제어의 흐름을 프레임워크가 주도하지 않는다면 의존성주입(DI)가 불가능하다.
- 이 질문에 답이 되기에는 힘들 수 있다. 그 이유는 제어의역전(IoC)이 없다면 관점지향프로그래밍(AOP), 등도 불가능하게 되기때문에 정확한 답변은 아니다.
- IoC의 분류 : IoC는 의존성 검색(Dependency Lookup, DL) 과 의존성 주입(Dependency Injection, DI) 로 나누어진다.
DL : 저장소에 저장되어 있는 Bean에 접근하기 위해 컨테이너가 제공하는 API를 이용하여 Bean을 찾아주는 것
DI : 각 클래스간의 의존관계를 빈 설정(Bean Definition) 정보를 바탕으로 컨테이너가 자동으로 연결해주는 것
- 이 질문에 답이 되기 가장 적합한 것 같다 그 이유는 DL과 DI는 IoC의 파생 분류이지만, 상대적으로 사용빈도가 적은 DL은 핵심모델에서 제외되었을 가능성이 높을것 같다.
두번째 🧐 추상화
추상화는 Java 시리즈에서 캡슐화와 함께 정리한 적이 있다. 참고사항
하지만 스프링에서 언급되는 서비스 추상화에 관한 사항이 빠져있기 때문에 추가해서 정리하자면,
추상화란?
불필요한 정보는 숨기고 중요한 정보만을 표현함으로써 공통의 속성이나 기능을 묶어 이름을 붙이는 것이다.
추상화의 따라 오는 이름들이 몇가지 있다
앞서 정리한 내용중에는
추상클래스 : 여러 클래스간 비슷한 피르와 메서드를 공통적으로 추출해 만들어진 클래스가 있고,
자료의 추상화 : 객체지향 관정에서 클래스를 정의하는 것도 있다.
그리고 Spring 프레임워크에서는 중요한 개념으로 서비스 추상화라는 것이 있다.
서비스 추상화란?
하위 시스템의 공통점을 뽑아내서 분리시키는 것을 말한다. 그렇게 하면 하위 시스템이 어떤 것인지 알지 못해도, 또는 하위 시스템이 바뀌더라도 일관된 방법으로 접근할 수 있다.
객체지향적인 코드는 다른 오브젝트의 데이터를 가져와서 작업하는 대신 데이터를 갖고있는 다른 오브젝트에게 작업을 해달라고 요청한다. 오브젝트에게 데이터를 요구하지 말고 작업을 요청하라는 것이 객체 지향 프로그래밍(OOP)의 가장 기본이 되는 원리이다.
일반적으로 서비스 추상화라고 하면 트랜잭션과 같이 기능은 유사하나 사용 방법이 다른, 로우레벨의
다양한 기술에 대해 추상 인터페이스와 일관성 있는 접근방법을 제공해 주는 것을 말한다.
트랜잭션(Transaction)이란? 사전적의미 : "쪼갤 수 없는 업무 처리의 최소 단위"
즉, 데이터베이스의 상태를 변화시키기 위해서 수행하는 단위를 뜻한다.
즉, 어댑터 패턴을 적용해 같은 일을 하는 다수의 기술을 공통의 인터페이스로 제어할 수 있게 한 것을 서비스 추상화라고 한다.
PSA란?
PSA는 Portable Service Abstraction으로 일관성 있는 서비스 추상화이다.
-
추상화 계층을 사용해서 어떤 기술을 내부에 숨기고 개발자에게 편의성을 제공해주는 것을 서비스 추상화(Service Abstraction)이라 한다.
-
서비스 추상화(Service Abstraction)로 제공되는 기술을 다른 기술 스택으로 간편하게 바꿀 수 있는 확장성을 갖고 있는 것이 Portable Service Abstraction이다.
Spring은 Spring Web MVC, Spring Transaction, Spring Cache 등의 다양한 PSA를 제공한다.
세번째 🧐 AOP
AOP는 인프런 스프링 입문에서 소개된 바가 있다.참고사항
마지막으로 AOP는
Aspect-Oriented Programming의 약자로 관점 지향 프로그래밍이라는 말이고,
흩어진 관점들을 모아서 모듈화하는 기법이다.
"관점지향"란 쉽게 말해 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것이다.
여기서 모듈화란 어떤 공통된 로직이나 기능을 하나의 단위로 묶는 것을 말한다.
Ex) 핵심적인 관점은 결국 우리가 적용하고자 하는 핵심 비즈니스 로직이 된다. 또한 부가적인 관점은 핵심 로직을 실행하기 위해서는 행해지는 데이터베이스 연결, 로깅, 파일입출력 등을 예로 들 수 있다
AOP에서 각 관점을 기준으로 로직을 모듈화한다는 것은 코드들을 부분적으로 나누어서 모듈화하겠다는 의미다. 이때, 소스 코드상에서 다른 부분에 계속 반복해서 쓰는 코드들을 반결할 수 있는데 이것을 흩어진 관심사라고 부른다.
즉, 위 그림과 같이 흩어진 관심사를 Aspect로 모듈화하고 핵심적인 비즈니스 로직에서 분리하여 재사용하겠다는 것이 AOP의 목적이다.
😁 통합정리
스프링은 애플리케이션을 구성하는 오브젝트가 생성되고 동작하는 방식에 대한 틀과 함께 애플리케이션 코드가 어떻게 작성되어야하는 지에 대한 기준도 제시해준다 이러한 틀을 프로그래밍 모델이라고 하고,
스프링 3가지 핵심 프로그래밍 모델은 "관심사의 분리"라는 목적을 두고 이루어지는 기법들이라고 할 수 있다.
References (참고 자료)
