Framework
프로그래밍을 위한 틀, 뼈대, 구조
ex) Collection Framework
장점
-
효율적으로 코드를 작성할 수 있음
✔️ 프레임워크가 라이브러리의 형태로 다양한 기능을 제공 -
효율적인 앱 관리
✔️ 프레임워크의 정해진 규약이 존재하고, 이 규약에 맞춰 작성하기 때문에 유지보수가 필요한 경우에 더 빠르고 쉽게 문제점을 해결할 수 있음 -
개발자가 핵심로직을 작성하는 데 집중할 수 있음
단점
- 프레임워크에 대한 학습이 필요
- 프레임워크의 규약을 벗어날 수 없기 때문에 자유롭고 유연한 개발이 어려움
Framework와 Library
주도권의 차이
❗️프레임워크 : 전체적인 프로그램의 틀
개발자가 메소드 내에 코드를 작성하면, 프레임워크는 개발자가 만든 코드를 사용해서 앱의 흐름을 만듦
➡️ 프레임워크가 주도권을 가진다
❗️라이브러리 : 특정 기능을 미리 구현해놓은 코드
개발자가 필요할 때 갖다 쓸 수 있음
➡️ 개발자가 주도권을 가진다
Spring Framework
Java 기반의 웹 애플리케이션 개발을 위한 Framework
장점
- POJO 기반 구성
- DI 지원
- AOP 지원
- Java 언어 사용
Spring Framework 이전에는 JSP(Java Server Page), Servlet을 사용했지만, 너무 복잡하고 가독성이 떨어짐
➡️ Spring MVC 방식 도입, but 여전히 불편
➡️ Spring Boot 등장!
Spring Framework의 특징
POJO (Plain Old Java Object)
순수한 자바 객체
❗️규칙
-
Java나 Java의 스펙에 정의된 것 이외에는 다른 기술이나 규약에 얽매이지 않아야 함 'Plain'
ex) 특정 기술을 상속받아 코딩하는 경우
➡️ 특정 기술에 종속적
➡️ 애플리케이션 요구사항이 바뀌는 경우 일일이 수정해야 함 -
특정 환경에 종속적이지 않아야 함
ex) servlet이 바뀌는 경우
➡️ 최악의 경우 전면 수정 필요
❗️POJO가 필요한 이유
- 재사용 가능, 확장 가능한 유연한 코드 작성 가능
- 종속적인 코드를 제거함으로써 코드가 깔끔해짐
- 디버깅이 쉬움
- 종속적이지 않아 테스트가 단순해짐
- 객체지향 설계를 제한없이 적용할 수 있음
Spring 에서는 POJO 프로그래밍을 지향하기 위해 IoC/DI, AOP, PSA 기술을 제공
IoC (Inversion of Control)
애플리케이션 흐름의 주도권을 Spring이 가짐
✔️순수 Java 콘솔 애플리케이션의 경우, main() 메소드를 실행시키며 개발자가 작성한 코드를 순차적으로 실행
❗️웹 상에서 돌아가는 서블릿 기반의 Java 웹 애플리케이션
➡️ 서블릿 컨테이너 내의 컨테이너 로직이 서블릿을 직접 실행
➡️ main() 메소드 필요 없음
➡️ 애플리케이션의 주도권은 서블릿 컨테이너에게 있음
IoC는 DI로 이루어짐
DI (Dependency Injection)
객체간의 의존성을 주입하는 것
생성자를 통해 어떤 클래스의 객체를 전달받아 의존성 주입을 구현
❗️DI가 필요한 이유
애플리케이션 내부에서 new 키워드를 직접 사용시 객체지향 설계의 관점에서 중요한 문제 발생
- 수정사항 발생 시
new키워드가 포함된 모든 코드를 수정해야 함 (강한 결합, Tight Coupling) - 하나의 객체가 아닌 모두 다른 객체를 가리키게 됨
➡️ 느슨한 의존성 주입으로 해결 ➡️ 인터페이스 사용
❗️BUT 최소한의 객체 생성을 위한 생성자는 ???
Spring 영역에서 해결!
Config : Config에 정의해둔 A객체를 Spring의 도움을 받아 B클래스에 제공
❗️Spring의 영역이기 때문에 애플리케이션에 관여 x
AOP (Aspect Oriented Programming)
관심 지향 프로그래밍, 공통 관심 사항을 분리하는 것
- 공통 관심 사항(Cross-cutting concern): 애플리케이션에 필요한 기능들에 대한 관심 사항 (ex.로깅)
- 핵심 관심 사항(Core concern): 애플리케이션의 핵심 로직에 대한 관심 사항 (ex.회원가입, 회원 조회)
회원가입과 회원조회 기능에 로깅이 공통으로 들어갈 경우, 모든 작업에 비슷한 코드를 작성하게 되면 유지보수가 어렵다!
해결
config에 Aop 클래스를 만들고 @Aspect, @Component 애너테이션을 붙여주어 공통 관심 사항을 분리
➡️ 직접 구현하지 않아 코드가 간결해짐
➡️ 코드의 재사용 가능
➡️ 원하는 적용 대상 지정 가능
PSA (Portable Service Abstraction)
클라이언트가 추상화된 상위 클래스를 일관되게 바라보며 하위 클래스의 기능을 사용하는 것
인터페이스에 접근하여 하위클래스의 기능 사용
➡️ 접근 방식 일관됨
➡️ 기술 자체를 유연하게 사용할 수 있음
❗️PSA가 필요한 이유
요구사항 변경 시 최소한의 수정으로 요구사항을 반영할 수 있음
➡️ 애플리케이션의 요구사항에 유연한 대처가 가능함
