🌈 [Section2] 16. Spring Framework 기본 1

📕 오늘 배운 내용!

• Framework
• Framework vs Library
• Spring Framework
• Spring Triangle / POJO
• Spring Framework의 3대 핵심 개념

---

✏️ Framework

• 프로그래밍을 하기 위해 기본적으로 어떠한 틀, 구조를 제공하는 것
  Ex. Java에서의 Collection
  ➜ Map, Set, List와 같은 인터페이스와 그 인터페이스를 구현한 구현체들의 집합
  ( 그 구현되어 있는 구현체들을 가져다 쓸 수 있음 )

✔ 장점

• 효율적인 코드 작성 가능
  ➜ Framework가 다양한 기능들을 라이브러리 형태로 제공
  ( 개발자가 애플리케이션의 핵심 로직 개발하는 것에 집중할 수 있도록 함 )

• 정해진 규약이 있어, 애플리케이션 효율적, 체계적으로 관리 가능
  ➜ Framework 규약에 맞게 코드를 작성하기 때문에, 유지보수 빠르고 쉽게 문제점 파악 후 수정 가능
  ➜ 다른 사람이 내 코드 수정할 경우에도, 빠르게 코드 파악 후 수정 가능

• 기본적이 설계와 필요한 라이브러리 제공해 생산성 향상

• 코드 재사용성 높고, 확장성 좋음

✔ 단점

• 사용하고자 하는 Framework의 규약들을 학습할 시간 필요 ( 러닝커브 존재 )

• 자유롭고 유연한 개발 어려움
  ➜ Framework의 규약을 벗어나기 어렵기 때문에, 이미 만든 구조 자체를 변경하게 될 경우, 만든 것들을 모두 허물고 새롭게 구조부터 다시 짜야함

✏️ Framework vs Library

✔ Library

• 도서관에 책들을 모아둔 것 처럼 필요한 기능들을 미리 만들어 두어 제공하는 것

• 구조 안의 요소들을 만들기 위해 이미 만들어져 있는 구현체들을 제공하는 것

• 쉽게 교체 가능

• 그 때 그 때 필요한 Library들을 선택적으로 사용 가능
  ( 짜 놓은 코드 내에서 필요한 기능이 있으면 해당 라이브러리를 호출해서 사용 )

➜ 애플리케이션 흐름의 주도권이 개발자에게 있음

✔ Framework

• 뼈대를 만들기 위해 이미 만들어져 있는 구현체들을 제공하는 것
• 교체가 어려움
• 개발자가 메서드 내에 코드를 작성해두면, Spring Framework에서 개발자가 작성한 코드를 사용해서 애플리케이션의 흐름을 만들어 냄

➜ 애플리케이션 흐름의 주도권이 Framework에 있음 (IoC (Inversion Of Control))

❗ 둘 다 애플리케이션을 개발할 때, 필요한 기능을 미리 구현해놓은 집합체라는 것은 동일하지만, 쓰이는 상황이 다름
⠀
❗ 애플리케이션에 대한 제어권의 차이가 있음

Ex. 자동차를 만드는 것을 예시로 든다면,

• Framework ➜ 자동차의 뼈대
• Library ➜ 자동차의 다양한 기능을 제공하는 부품

✏️ Spring Framework

• 여러 Framework 중 한 종류

• 객체 지향 설계 원칙에 잘 맞는 재사용과 확장이 가능한 애플리케이션 개발 스킬을 향상시킬 수 있음

• 보다 나은 성능과 서비스의 안전성이 필요한 복잡한 기업용 엔터프라이즈 시스템을 제대로 구축하기 위한 능력 기를 수 있음

✔ Spring Framework만의 장점

• POJO(Plan Old Java Object)기반의 구성

• DI(Dependency Injection) 지원

• AOP(Aspect Oriented Programming, 관점지향 프로그래밍) 지원

• Java 언어를 사용함으로써 얻는 장점
  ➜ 변수 타입, 메서드 입출력이 어떤 타입을 가져야하는지 강제하기 때문에, 코드의 수정/보안이 용이하고 웹서버 구축 시 런타입에 발생하는 오류를 사전에 방지 가능

❗ Java 언어를 사용하는 다른 Framework들도 많음
Ex. Apache Struts2, Apache Wicket, JSF(Java Server Faces), Grails 등
⠀
❗ But, 대부분의 기업들이 기업용 엔터프라이즈 시스템용 애플리케이션을 개발 할 때,
개발 생산성이 좋고 유지 보수가 좀 더 용이한 Framework인 Spring Framework를 주로 사용

✔️ 기업용 엔터프라이즈 시스템

• 기업의 의무를 처리해주는 시스템
  Ex. 고객을 위한 서비스, 조직적 의무
  ➜ 대량의 사용자의 요청 처리를 위해 서버의 자원 효율성, 보안성, 시스템의 안정성, 확장성 등을 충분히 고려해서 시스템 구축함

✏️ Java 기반 웹 애플리케이션 개발의 흐름

1. 초창기 -> JSP(Java Server Page) 사용

• 클라이언트 측 HTML/JS 코드와 서버 측 Java 코드가 뒤섞여있는 방식

• 가독성도 떨어지고 너무 복잡 ( 애플리케이션 유지 보수 측면에서 최악의 방식 )

• 협업의 거의 불가능

2. 서블릿(Servlet) 사용

• JSP 코드에서 Java 코드만 별도의 서블릿 클래스로 분리한 방식
  ( 클라이언트 웹 요청 처리에 특화된 Java 클래스의 일종 )
  ( JSP 방식도 내부적으로는 Servlet 방식 사용 )

• 개발자가 별도로 데이터를 꺼내오는 작업을 직접 코드로 작성도 해야 하고 캐릭터셋도 지정해주어야 함

• 비즈니스 로직도 없고 데이터 액세스 로직도 없는데 코드 자체가 너무 긺

3. Spring MVC 사용

• 눈에 보이지 않지만 서블릿에서 개발자가 직접 해야했던 일들을 Spring에서 알아서 처리해줌

• 이 방식이 도입됨으로써 Java 웹 애플리케이션의 제작방식이 획기적으로 변함

• But, Spring 기반의 애플리케이션의 기본 구조를 잡는 설정 작업이 여전히 불편
  ( Spring 애플리케이션을 정상적으로 구동하기 위해 써야하는 설정 파일들이 복잡 )

4. Spring Boot 사용

• 이 전의 문제들이 대부분 개선됨

• Spring MVC 설정의 복잡함과 어려움의 극복을 위해 탄생

• 이 전 방식들을 모두 클라이언트가 전달한 요청 데이터를 테스트 목적으로 단순히 List에 담았는데, 이 방식은 데이터베이스에 저장해서 데이터 액세스 처리까지 하도록 함

• 데이터를 실제로 저장하는 기능 추가

• 코드 길이는 크게 바뀐 것이 없고 오히려 더 깔끔해짐

• 설정파일도 Spring이 대신 처리해주어 아주 간단
  ➜ 개발자는 애플리케이션의 핵심 비즈니스 로직에만 집중 가능

---

✏️ Spring 삼각형 (Spring Triangle)

⬆️ POJO라는 것을 IoC/DI, AOP, PSA를 통해서 달성할 수 있다는 것을 의미

---

✏️ POJO (Plain Old Java Object)

• Java로 생성하는 순수한 객체

✔ POJO 프로그래밍

• POJO를 이용해서 프로그래밍 코드를 작성하는 것

• But, 단순히 순수 자바 객체만으로 사용한다는 말이 아니라,
  객체지향의 원리에 충실하며 다른 환경과 기술에 종속되지 않고 다른 기술과 규약에 얽매이지 않은 객체

✔ POJO 규칙

1. Java 언어 외에 다른 기술이나 규약에 얽매이지 않아야 함
➜ 특정 기술을 상속해서 코드 작성할 경우 그 클래스를 명시적으로 사용했던 부분을 일일이 모두 수정해야하고 다중 상속을 지원하지 않기 때문에 한 번 상속하면 객체 지향 설계 기법 적용이 어려워짐

2. 특정 환경에 종속적이지 않아야함

• 특정한 프레임워크에서만 동작이 가능하면 안됨
  ➜ 그 환경 변하면 다 갈아엎어야 하니까

• 웹 기반의 환경정보/웹 기술을 담고있는 클래스 or 인터페이스를 사용하면 안됨
  ( 웹에서만 동작하는 api를 직접 사용하면 안됨 )
  ( But, 다른 api들도 사용을 아예 안하기엔 확장성 측면에서 불리할 수 있기에 최대한 안쓰려고 하면서 써야할 경우엔 쓰기 )

3. 객체 지향 원리 따라야 함

• 단순히 Java로 구현했다고 해도 모두 객체 지향적 설계가 적용됐다고 하긴 어려움

• 책임 / 역할이 분명히 나누어져야 함 (객체지향의 5대 원리 SOLID )
  ➜ 하나의 클래스에는 하나의 책임 / 역할만 존재해야 함
  ➜ 상속, 다형성을 활용해야 함
  ➜ 조건문만을 활용하여 설계된 오브젝트는 POJO가 아님

✔ POJO 프로그래밍이 필요한 이유

• 특정 환경이나 기술에 종속적이지 않으면 재사용 가능하고, 확장 가능한 유연한 코드 작성 가능

• 저수준 레벨의 기술과 환경에 종속적인 코드를 애플리케이션 코드에서 제거
  ➜ 코드가 깔끔해짐
  ➜ 디버깅도 상대적으로 쉬워짐

• 특정 기술이나 환경에 종속적이지 않기 때문에 테스트도 단순

• 객체지향적인 설계를 제한없이 적용 가능 (가장 중요)

✔ POJO와 Spring의 관계

Spring Framework 사용 전에는 원하는 특정 기술이 있다면 그것을 직접적으로 사용하는 객체를 만들어 사용함
But, 프로젝트가 커지면서 유지, 보수, 확장이 어려워지고 Java 언어는 사용하지만 객체지향 설계의 본질을 잃어버리는 문제점이 생김
➜ POJO 개념 등장

• 좋은 객체 지향 설계를 위한 Spring은 POJO 프로그래밍을 지향하는 Framework이고,
  이 POJO 프로그래밍 코드를 사용하기 위해 IoC/DI, AOP, PSA 기술을 지원
  ( 최대한 다른 환경, 기술에 종속적이지 않도록 하기 위해 )

🔥 애플리케이션 프로그래밍 코드를 작성할 때,
항상 내가 작성한 코드가 객체지향스러운가에 대한 고민을 하는 습관을 가지는 것이 중요!
POJO 프로그래밍을 효과적으로 적용하기 위해서는 특정 기술에 대한 지식보다는 JDK의 API에 대한 지식과 객체지향적인 사고방식과 설계를 위한 훈련이 우선시 되어야 함

---

✏️ Spring Framework의 3대 핵심 개념

1. IoC (Inversion of Control)

• 애플리케이션 흐름의 주도권이 뒤바뀐 것
  Ex. Framework은 애플리케이션 흐름의 주도권이 개발자가 아닌 Framework에 있는 것 처럼

• 클래스 간의 결합도를 낮추기 위한 중요한 방법 ( 인터페이스 사용 )

✔️ 개발자가 제어권을 갖는다

• 개발자가 작성한 코드 안의 객체를 내 맘대로 갈아 끼울 수 음
• 개발자가 작성한 코드 대로 코드의 흐름이 진행됨
• 해당 클래스가 어떤 객체를 의존하고 있는지 개발자가 알고 활용해야함

✔️ 제어권을 외부로 넘긴다 ( IoC ) ( 개발자 -> 외부 )

• 객체의 생명 주기에 대한 관리를 개발자가 직접 하지 않음
  Ex. 삭제, 의존관계 주입, 생성
• 해당 클래스가 어떤 객체를 의존하고 있는지 몰라도 됨

Ex 1. 여행을 가려고 APackage 구매함
( 여기서 APackage의 여행경로는 Acourse ➜ Bcourse ➜ Ccourse 로 정해져 있음 )

• 이 경우에는 생성자에 직접 객체를 넣어주게 됨
  ➜ APackage라는 제어권이 객체 내부에 있는 것
  ⠀
• 여기서 고객이 다른 코스를 넣어달라고 하면 불가능
  ➜ 위와 같이 짜여진 코드에서는 큰 변경이 일어나야함

---

Ex 2. 위의 예시를 Spring Framework로 만든다면,

• 이 경우에는 생성자가 추상화된 TourGuide라는 인터페이스를 요소로 받는 리스트를 받고 있음
  ⠀
• 원하는 course의 객체를 리스트에 직접 넣어주면 APackage에 그 course들이 담김
  ( 여기서 주입되는 각 course들은 TourGuide라는 인터페이스를 구현한 구현 클래스들 )
  ⠀
  ➜ APackage라는 제어권이 외부에(고객에게) 있음
  ( 생성자 부분에서 의존성 주입이 이루어짐 )

✔️ 보통 Java 콘솔 애플리케이션의 제어 흐름

• main() 메서드가 있어야 실행
  ➜ System 클래스를 통해 static 멤버변수인 out의 pritln() 호출
  ( main() 메서드가 종료되면 애플리케이션의 실행도 종료 )

✔️ 할리우드 법칙 (Hollywood Principle)

• Don't call us, we'll call you
• 저희를 부르지 마세요 저희가 알아서 부를게요

2. DI (Dependency Injection) ( 의존성 주입 )

• IoC 개념을 사용하기 위한 방법

• 생성자를 통해서 어떤 클래스의 객체를 전달 받는 것

  ✔️ 외부에서 객체를 주입한다
  ➜ 생성자의 파라미터로 객체를 전달하는 것

Ex. A 클래스가 B 클래스의 구현 클래스일 때,
<A 클래스는 B 클래스에게 의존한다> 라고 함
( 도움을 받는 쪽이 A / 도움을 주는 쪽이 B )

Ex. 기능을 만들어 놓은 A 클래스와, main 클래스를 가지고 있는 B 클래스가 있다고 할 때,
B 클래스에서 new 키워드로 A 클래스의 객체를 생성하고, 이 객체로 A 클래스의 메서드를 호출한다면
사용하고자 하는 클래스의 객체를 생성해서 참조하게 되면 의존관계까 성립한 것

✔️ 클래스 다이어그램
애플리케이션 설계를 위해 굉장히 많이 사용하는 다이어그램
애플리케이션 구현에 필요한 클래스들의 큰 그림을 그려보기 위해 사용
[참고] https://online.visual-paradigm.com/diagrams/features/

✔ 강한 결합

• new 키워드 사용하여 객체를 생성하여 의존성 주입하는 것
  ➜ 수정할 내용이 있으면 다 일일이 수정해야함
  ➜ 업캐스팅으로 인터페이스 사용해서 느슨한 결합 해야함

  ✔️ 업캐스팅
  ➜ 인터페이스 타입의 변수에 그 인터페이스의 구현 객체를 할당

✔ 느슨한 결합

• new 키워드 제거하고 Spring을 사용하여 의존성 주입하는 것
  ( new 키워드로 객체 생성하던 것을 Spring이 대신 함 )

➜ 완전히 Spring Framework 영역의 클래스에 객체를 정의해두고 Spring의 도움을 받아, 다른 클래스에 의존 객체들을 주입하는 것
( Spring Framework 영역의 클래스는 실제 애플리케이션의 핵심 로직에 관여하지 않음 )

➜ 수정이 많은 경우에도 Spring Framework 영역에 있는 클래스를 변경해주기만 하면 됨

❗ 객체지향의 5대 원칙 SOLID 중 DIP(Dependency Inversion Principle)도 같이 생각해 보기 !

3. AOP (Aspect Oriented Programming)

• 관점 지향 프로그래밍

  ✔️ Aspect
  ➜ 애플리케이션의 공통 관심사
  ( 뭔가 공통적인 처리가 필요할 때 사용하는 개념 )

• 애플리케이션의 핵심 업무 로직(비즈니스 로직)에서 공통 기능 로직들을 분리하는 것
  Ex. 공통 기능 - 로깅이나 보안, 트랜잭션, 모니터링, 트레이싱 등

➜ 공통 로직들을 Aspect로 분리하고 해당 Aspect가 사용되는 메서드 매핑

✔️ 모듈화
공통 관심 사항의 분리 + 매핑

• 재사용이 가능하도록 모듈성을 증가시키는 것이 목적
  Ex. 중복된 코드들이 많다면, 이 중복된 코드를 AOP를 사용해 공통화해서 재사용이 가능하도록 만들어야 함

✔️ 공통 관심 사항(Cross-cutting concern)

• 애플리케이션 전반에 걸쳐 공통적으로 사용되는 공통 기능들에 대한 관심사
• 핵심 로직에 전반적으로 두루 사용됨
  Ex. 보안

✔️ 핵심 관심 사항(Core concern)

• 애플리케이션의 주목적을 달성하기 위한 핵심 로직(비즈니스 로직)에 대한 관심사
  Ex. 기능
• 핵심 관심 사항에 반대되는 개념으로 공통 관심 사항을 부가적인 관심 사항이라고 표현하기도 함

[참고] https://velog.io/@geesuee/Spring-AOPAspect-Oriented-Programming%EC%99%80-%ED%94%84%EB%A1%9D%EC%8B%9C

✔ AOP가 필요한 이유

• 코드의 간결성 유지

• 객체 지향 설계 원칙에 맞는 코드 구현

• 공통 코드의 재사용
  ( 핵심 로직에 공통 기능들이 여기저기 보이면 코드도 복잡해지고 유지/보수 모두 힘듦 )

Ex. 클래스 내부에 트랜잭션 처리를 위한 rollback(), commit() 등과 같은 코드는 모두 사라지고 비즈니스 로직만 처리하는 코드만 남김
그리고 이 트랜잭션 처리는 애노테이션을 붙여 Spring 내부에서 AOP 기능을 통해 트랜잭션 적용하도록 함

❗ 자신이 구현한 코드를 깔끔하고, 재사용 가능하게 유지하려고 끊임 없이 노력해야함
➜ 객체지향적인 사고

4. PSA (Portable Service Abstraction)

• 일관된 서비스 추상화

  ✔️ 추상화
  ➜ 어떤 클래스의 본질적인 특성만 추출해서 일반화 하는 것
  ( 추상 클래스 / 인터페이스 사용 )

• 추상화된 상위 클래스를 일관되게 바라보며 하위클래스의 기능을 사용하는 것
  ( 상위클래스가 애플리케이션에서 이용하는 하나의 서비스 )

Ex. 클라이언트(main())가 하위 클래스를 이용할 때, 직접적으로 이용하지 않고 상위 클래스 인터페이스를 통해 간접적으로 이용(느슨한 결합) )
➜ 인터페이스를 사용하는 클라이언트는 뭐가 수정되었는지 몰라도 됨

• 서비스의 기능을 접근하는 방식 자체를 일관되게 유지하면서, 기술 자체를 유연하게 사용할 수 있도록 하는 것

• 환경의 변화에 상관 없이 일관된 방식(환경)으로 제공하는 추상화 구조
  ➜ 인터페이스에서 추상 메서드를 만들 듯, 추상화된 서비스를 통해 환경이 바뀌어도 황용할 수 있어야함
  ➜ DI를 활용해 사용할 객체만 바꿔주도록 구현

✔ PSA가 필요한 이유

• 어떤 서비스를 이용을 위한 접근 방식을 일관된 방식으로 유지함으로써, 애플리케이션에서 사용하는 기술이 변경되더라도 최소한의 변경만으로 변경된 요구 사항을 반영하기 위함
  ➜ 애플리케이션의 요구 사항 변경에 유연하게 대처
  Ex. 트랜잭션 서비스, 메일 서비스, Spring Data 서비스 등

---

🌈 느낀점

뭔가 아직까지는 잘 머릿속에 정리가 되진 않는다
머리가 어질,,
하지만 그래도 각 개념들의 목적 정도는 이해를 했으니 앞으로 본격적으로 배우면서 차차 더욱 이해해 나갈 것이다