[Spring 강의] Spring이란?

1. Spring 이란?

Spring 은 특정한 하나를 뜻하는게 아니라, 여러 기술들의 모음이라고 볼 수 있다. Ex) 스프링 홈페이지

스프링 프레임워크, 스프링 부트를 포함하여, 프스필 데이터, 스프링 세션, 스프링 시큐리티 등..을 포함한다.

가장 큰 핵심은 스프링 프레임워크이고 ,이를 편리하게 쓸 수 있도록 하는게 스프링 부트이다.

요즘은 스프링 부트를 주로 활용해서 스프링 프레임워크를 사용한다고 한다.

Spring 프레임 워크 기능들

• 핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타
• 웹기술: 스프링 MVC, 스프링 WebFlux
• 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원
• 기술 통합: 캐시, 이메일, 원격 접근, 스케줄링
• 테스트: 스프링 기반 테스트 지원
• 언어: 코틀린, 그루비

스프링 부트는 웹 서버를 내장하고 있기 때문에 따로 웹서버를 설치 않아도 되는 장점이 있다.

또한 starter가 외부 라이브러리도 다 알아서 끌어와주며 외부 라이브러리 버전 최적화가 되어있고, 메트릭 모니터링등을 지원해준다는 장점이 있어서 최근에 기본으로 사용 된다고 한다.

하지만, 스프링 부트를 사용한다는 뜻이 스프링 부트와 스프링 프레임워크와 별도로 사용한다는 뜻이 아니다.

스프링 부트를 도와주는 프로그램이라고 생각하면 된다!

그렇다면 스프링을 왜 만들었을까?

Spring은 자바 언어 기반의 프레임워크로, 객체지향 언어가 가진 강력한 특징을 살려내는 프레임 워크이다.

즉, 좋은 객체 지향 어플리케이션을 개발할 수 있도록 도와주는 프레임워크이다!

기술의 핵십 컨셉은 항상 단순하게 시작하는 것이다. 이 컨셉이 좋으면 점점 살이 붙으면서 커지는 것이다.

Spring은 로드 존슨의 3만줄에서 시작되었다✨

2. 좋은 객체 지향 프로그래밍?

객체 지향 프로그래밍

⇒ 객체들의 모임으로 프로그램을 이해하는 것. 즉 객체들이 서로 메세지, 데이터 를 주고 받고 협력을 하는 것

⇒ 유용하고 변경이 용이한 장점이 있다.

⇒ 부품을 갈아끼우듯이 프로그래밍을 할 수 있다는 것@!

다형성(Polymorphism)

• 실세계의 자동차를 예로 들어보자.

  운전자와 자동차가 있을 때, 주인이 자동차를 바꾸더라도 운전을 하는데 문제가 없다.

  여기서 자동차를 바꾸는 게 다형성이 의미하는 것이다.

  
  

  ⇒ 자동차 역할의 인터페이스가 정해져있고 이것에 따라 만들었기 때문에, 클라이언트가 내부 구조를 알 필요가 없고 객체가 자신의 역할을 하고 있다면 문제가 없다.

  ⇒ 즉, 역할과 구현으로 세상을 구분했기 때문에, 새로운 자동차가 나와도 클라이언트는 운전을 새로 배우지 않아도 된다.

  ⇒ 자동차의 세계를 무한히 확장 가능한 것이다.

  ⇒ 클라이언트에게 영향을 주지 않고 새로운 기능을 제공 할 수 있는 것이다!

  
  

  다른 예시 ex) 공연 무대(각 주인공이 자기 역할만 제대로 소화하면 상대방이 누구든 문제가 없다.), 키보드, 마우스 등등

• 역할과 구현을 분리

  • 세상이 단순해지고,유연해지며 변경도 편리해진다.

  • 클라이언트는 대상의 역할(인터페이스)만 알면 된다.

  • 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.

  • 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.

  • 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

    
    

이걸 자바에 적용 하면 아래와 같이 정의가 가능하다.

• 역할 = 인터페이스
• 구현 = 인터페이스를 구현한 클래스, 구현 객체

프로그램은 객체의 협력이라는 관계부터 생각해야 한다.

혼자 있는 객체는 없고, 수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다.

구현보다 인터페이스가 먼저이고, 협력이라는 관계에서 시작하는 것이 다용성의 본질이다!

정리하자면, 역할과 구현을 분리 하는 것은

장점

• 실세계의 역할와 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져올 수 있음
• 유연하고, 변경이 용이
• 확장 가능한 설계
• 클라이언트에 영향을 주지 않는 변경이 가능
• 인터페이스를 안정적으로 잘 설계하는 것이 중요!

한계

• 역할(인터페이스)자체가 변하면, 클리아언트, 서버 모두에 큰 변경이 발생

인터페이스를 제대로 설계 하는게 가장 중요하다.

이후에 가장 크게 변하지 않고 기능 업데이트 및 추가 가능하기 때문이다.

객체 지향의 꽃은 다형성이고, 스프링은 이를 극대화 할 수 있도록 도와주는 것이다.

3. 좋은 객제지향 설계의 5가지 원칙(SOLID)

SOLD : 클린 코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리

• SRP: 단일 책임 원칙(single responsibility principle)

• OCP: 개방-폐쇄 원칙 (Open/closed principle)

• LSP: 리스코프 치환 원칙 (Liskov substitution principle)

• ISP: 인터페이스 분리 원칙 (Interface segregation principle)

• DIP: 의존관계 역전 원칙 (Dependency inversion principle)

  *앞글자를 따서 만듬

📝 SRP: 단일 책임 원칙

• 한 클래스는 하나의 책임만 가져야 한다. (문맥과 상황에 따라 다르다)

• 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것

  ⇒ 기능이 업데이트, 추가 될때 얼마나 변경이 적게 필요한지가 중요 포인트

• Ex) UI 변경, 객체의 생성과 사용을 분리 ⇒ 적절하게 조절하는게 묘미이다.

  
  

📝 OCP: 개방-폐쇄 원칙 ✔️중요

• 소프트웨어 요소는 확장에 열려 있지만 변경에는 닫혀 있어야 한다.

• 구현 객체를 변경하려면 클라이언트의 코드를 변경해야 하는 경우가 생긴다.

  이럴때는 다형성을 활용해야 한다! ⇒ 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.

📝 LSP: 리스코프 치환 원칙

• 간단히 말하자면, 어떤 인터페이스가 있고 구현체가 있다면 인터페이스의 의도와 같이 만들어야 한다.

  즉, 기능적으로 보장을 해야 하는 것이다.

  ⇒ 자동차의 엑셀을 밟으면 뒤로 가는게 아니라 앞으로 가야한다. 느리더라도 앞으로 가는게 맞는 것!

  
  

📝 ISP: 인터페이스 분리 원칙

• 간단히 말하자면 인터페이스를 작게 나누는 것이라 볼 수 있다.

  자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스로 분리

  자동차가 인터페이스 하나가 너무 크니깐 운전이랑 정비로 따로 나누는 것이다.

  그럼 사용자 인터페이스도 나눌 수 있다!

  인터페이스가 명확해지고 대체 가능성이 높아진다.

  
  

📝 DIP: 의존관계 역전 원칙 ✔️중요

• 쉽게 말하면 클라이언트 코드가 구현 클래스를 바라보지 말고 인터페이스만 바라보자라는 것이다.
• 역할과 구현을 철저하게 분리해서 시스템을 언제가 갈아 끼울 수 있도록 만드는 것이다.
• 역할(Role)에 의존해야 한다. 클라이언트가 인터페이스에 의존해야 한다.

여기까지 정리,

• 객체 지향의 핵심은 다형성
• 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.
• 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
• 다형성 만으로는 OCP, DIP를 지킬 수 없다.

그렇다면 어떻게 해야하는가?

4. 객체 지향 설계와 스프링

스프링이야기에 왜 객체 지향 이야기가 나오는가?

• 스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원
• DI(Dependency Injection): 의존관계, 의존성 주입
• DI 컨테이너 제공
• 클라이언트 코드의 변경 없이 기능 확장
• 쉽게 부품을 교체하듯이 개발

그렇기 때문에 스프링을 사용 하는 것이다!

5. 최종 정리

• 모든 설계에 역할과 구현을 분리하자.
• 자동차, 공연의 예를 떠올려보자.
• 애플리케이션 설계도 공연을 설계 하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계다.
• 이상적으로는 모든 설계에 인터페이스를 부여하자
• 변경의 범위가 작고 유연해진다.

하지만, 인터페이스를 도입하면 추상화 비용이 발생한다.

추상화가 되면 개발자가 한번 더 코드를 열어서 구현 케이스가 무엇인지 한번 더 봐야 한다.

즉, 장점이 단점이 늘어날 때 적용하는 게 좋다.

(확장 가능성이 없으면 인터페이스를 없이 그대로 쓰고, 나중에 리팩토링을 하는 것도 하나의 방법이다.)

🌿 인프런 스프링 핵심 원리 기본편: 김영한 님의 강의를 듣고 정리한 내용입니다.