1일1개 (8) - Spring 왜 쓸까 ?

1일 1개념정리 24.08.09.금 ~ 

 

큰 결정에 큰 동기가 따르지 않을 때도 있다. 하지만 큰 결심이 따라야 이뤄낼 수 있다.

무조건 무조건 1일 1개의 개념 정리하기 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!

---

#8. Spring 왜 쓸까 ?

예전에 비슷한 글을 썼지만 좀 부족해 보여서 보완하여 다시 써본다.

 

요기 문서를 참고하였다.

https://www.javatpoint.com/spring-tutorial

 

1) Predefined Templates

JDBC, Hibernate, JPA 등 여러 템플릿을 제공하여 더 적은 코드를 사용하도록 도와준다.

2) Loose Coupling ★★★

Dependency Injection 덕분에 결합도를 느슨하게 만들어준다. DI 관련은 다음 포스팅을 참고하자.

https://100won-developer.tistory.com/entry/Inversion-of-Control

Inversion of Control (Bean내용 포함)

 

간단하게 이야기하자면, 이렇다. 일단 의존성 주입이라는 뜻 자체가 객체 간의 의존 관계를 외부에서 주입해주는 디자인패턴의 하나이다. 이는 객체가 자신의 의존성을 직접 생성하거나 관리하지 않고, 외부에서 주입받는 것을 의미한다.

 

글로만 보면 이해가 안되니 코드로 보자.

 

(1) DI 없이 직접 결합

public class A {
    private B b;

    public A() {
        this.b = new B();  // A가 B를 직접 생성함
    }

    public void doSomething() {
        b.someMethod();
    }
}

이 방식은 강한 결합도를 초래한다. 왜냐? 클래스 A에서 B를 직접적으로 가져다가 쓰고 있기 때문이다 ... 만약 B 클래스가 변경되면?? 그럼 A 클래스도 영향을 받을 수 있다 .

 

(2) DI 사용

public class A {
    private B b;

    public A(B b) {  // 생성자 주입
        this.b = b;
    }

    public void doSomething() {
        b.someMethod();
    }
}

이 경우 A 클래스는 B 클래스의 인스턴스가 어떻게 생성되었는지 알 필요가 없으며, 단지 B 클래스가 주입된다는 사실만 알면 된다. 이를 통해 A 클래스와 B 클래스 간의 결합도가 느슨해진다 !!

 

DI를 하는 방법은 3가지가 있다.

1. 생성자 주입 (Constructor Injection) ----- 권장하는 방식
   •    객체가 생성될 때 의존성을 생성자를 통해 주입받는 방식
   •    의존성이 필수적일 때 유용
2. Setter 주입 (Setter Injection)
   •    객체가 생성된 후, setter 메서드를 통해 의존성을 주입
   •    선택적 의존성을 주입할 때 유용
3. 필드 주입 (Field Injection) ----- 권장 X
   •    객체의 필드에 직접 의존성을 주입하는 방식 (@Autowired 어노테이션을 사용)
   •    테스트가 어려워질 수 있고, 권장되진 않는다.

이 내용에 대한 자세한 설명은 아래 포스팅을 참고하자 !!!

 

https://100won-developer.tistory.com/entry/Inversion-of-Control

Inversion of Control (Bean내용 포함)

 

(2-1) DI의 장점 ★ ★ ★

• 유연성 : 의존성 주입을 통해 각 객체는 자신의 책임에만 집중할 수 있다. 이로 인해 객체들 간의 결합도를 낮추고, 코드를 보다 유연하게 만든다.
• 테스트 용이성 : DI를 사용하면 목(mock)테스트를 통해 의존 객체를 쉽게 교체할 수 있어 단위 테스트가 훨씬 쉬워진다.
• 재사용성 : 느슨한 결합 덕분에, 객체를 다양한 환경에서 재사용하기 쉬워진다.
• 유지보수성 : 의존성 주입을 통해 코드의 유지보수가 용이해지고, 객체 간의 의존 관계를 명확하게 파악할 수 있다.

 

내 생각) 사실 스프링에서 가장 핵심적이고, 스프링이 뛰어나다는 평가는 이 DI때문이 아닌가 싶다.

 

3) Easy to test

서버 실행 없이도 테스트하기가 쉬워졌다. 실제로 Spring으로 개발할 땐 테스트에 신경쓰며 개발하기도 하니 말이다. Spring이 TDD를 지향하면서 단위 테스트도 더욱 간편해졌다.

 

내 생각) 사실 스프링으로 하는 프로젝트가 워낙 거대해서 실행하기보다 테스트하는 게 더 이득이라 테스팅 라이브러리 등이 발전한 게 아닐까 ??

4) Lightweight

스프링은 POJO를 구현한 덕분에 가볍다. POJO 기반 구성덕분에 특정한 클래스를 상속받거나, 인터페이스를 구현하라고 강제하지 않는다. 즉, 특정 라이브러리나 기술에 종속적이지 않는 개발을 할 수 있다.

 

* POJO(Plain Old Java Object) = 주요 Java 오브젝트 모델, 컨벤션 또는 프레임워크를 따르지 않는 Java 오브젝트

 

내 생각) 보통 경량급이라고 하면 Flask같은 파이썬 계열을 떠올리는데... 왜 스프링이 경량급이라는 것일까 ?? 사실 스프링 자체만을 놓고 보면, 소스코드도 참 길고, 모듈도 수십개인데 경량급은 아닌 것으로 보인다. 아마... 기존의 것들을 획기적으로 대체해서 가벼워졌다는 뜻이 아닐까? 애당초 Spring도 어렵게 코딩하던 시절에 봄이 왔다 해서 스프링이라고 지었다고 하니.... EJB 시절(엔터프라이즈 자바빈즈)보단 가벼워졌다..?? 라는 의미가 아닐까 싶다.

수정)) 예전엔 이렇게 생각했는데, 지금 보니 약간 허점이 뭐냐면, "모듈이 수십개"라는 것은 필요한 모듈만 선택적으로 사용이 가능하다는 뜻이기도 하다. 그래서 프레임워크 전체를 쓰는 것이 아닌, 필요한 기능만 가져와서 쓰는 것이라 가벼워질 수 있다.

그 외에 나머지 내용들은 대체로 맞는 표현인 것 같다. Spring이 추구하는 구조, 기능 등이 원래는 더 복잡한 코드였지만 이제는 많이 추상화되고 모듈화되면서 가벼워졌다고 한다.

 

5) Fast Development

제공되는 여러 기능들로 빠르게 개발할 수 있다. 어노테이션도 많고, start.spring.io에서는 쉽게 라이브러리들도 주입해주니 편하다. 또한 커뮤니티도 참 많고 오픈소스도 많아서 좋다는 것도 장점이다. 물론 동시에 파이썬 등 많은 언어의 장점이기도 하다.

 

내 생각) 근데 체감상 팀 프로젝트를 할 땐 스프링이 제일 느린 것 같다.... 그 이유는 아마 학부생은 아직 다루는 게 미숙해서인 것 같다.

6) Powerful abstraction

JDBC, JPA같은 강력한 추상화를 제공한다.

 

 

이 외에도 스프링의 핵심 3요소를 본다면 구조적으로 잘 짜여져있음을 느낄 수 있다.

(참고)

https://100won-developer.tistory.com/entry/Inversion-of-Control

https://100won-developer.tistory.com/entry/Aspect-Oriented-Programming

https://100won-developer.tistory.com/entry/Portable-Service-Abstraction

 

 

스프링의 단점...은 아니고 어려운 점

사실 단점까지는... 아니지만 스프링을 쓰면 계속해서 공부해야 한다는 점이 참 어렵다. 모든 공부가 그렇고 컴퓨터쪽이 더 그런 건 맞지만... 몇개월 전에 출판된 책을 샀고 그대로 따라 쳤는데 실행되지 않는 건 아직도 당황스럽다..... (spring security 할 때 최근에 느낀 것이다... security 6.0으로 넘어가면서 문법도 바뀌고 deprecated된 것도 많아서 참 어려웠다....)