스프링 핵심 원리 (1)

so2·2021년 8월 8일
0
post-thumbnail
post-custom-banner
  • 스프링이란 ?

    • 문맥에 따라 다르게 사용됨
    • 스프링 DI 컨테이너 기술
    • 스프링 프레임워크
    • 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계
  • 스프링의 핵심 가치

    • 스프링은 자바 언어 기반의 프레임워크
    • 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크
  • 객체지향 특징

    • 추상화
    • 캡슐화
    • 상속
    • 다형성
  • 객체 지향 프로그램

    • 역할과 구현을 분리 → 단순해지고 유연해지며 변경도 편리해진다
      • 장점
        • 클라이언트는 대상의 역할(인터페이스)만 알면 된다
        • 클라이언트는 구현 대상의 내부 구조를 몰라도 된다
        • 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다
        • 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다
    • 자바에서
      역할 = 인터페이스
      구현 = 인터페이스를 구현한 클래스, 구현 객체
    • 객체를 설계할 때 역할과 구현을 명확히 분리
    • 객체 설계시 역할을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기 (중요!!)
    • 인터페이스를 안정적으로 잘 설계하는 것이 중요
  • 좋은 객체 지향 설계의 5가지 원칙 (SOLID - 로버트 마틴)

    • single resposibility principle (SRP) : 단일 책임 원칙
      • 한 클래스는 하나의 책임만 가져야 한다
      • 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
    • Open/closed principle(OCP) : 개방-폐쇄 원칙
      • 확장에는 열려 있으나 변경에는 닫혀 있어야 한다
    • Liskov substitution principle (LSP) : 리스코프 치환 원칙
      • 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다
      • 하위 클래스는 인터페이스 규약을 다 지켜야 한다
    • Interface segregation principle (ISP) : 인터페이스 분리 원칙
      • 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
      • 자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스로 분리
      • 분리하면 정비 인터페이스가 변해도 운전자 클라이언트에 영향을 주지 않음
      • 인터페이스가 명확해지고, 대체 가능성이 높아진다
    • Dependency inversion principle (DIP) : 의존관계 역전 원칙
      • 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다
      • 구현 클래스에 의존하지 말고, 인터페이스에 의존해야 한다
      • 역할에 의존하게 해야 한다
  • 다형성의 본질

    • 인터페이스를 구현한 객체 인스턴스를 실행 시점에서 유연하게 변경할 수 있다
    • 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다
  • 다형성 만으로는 OCP, DIP를 지킬 수 없다

  • 스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원

    • DI : 의존관계, 의존성 주입

    • DI 컨테이너 : 자바의 객체들을 컨테이너 안에 넣고 의존관계를 서로 연결, 주입

      클라이언트 코드의 변경 없이 기능 확장이 가능하다

  • Inversion of Control (IoC) : 제어의 역전

    • 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것
  • Depencency Injection (DI) : 의존관계 주입

    • 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다
    • 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존관계 둘을 분리해서 생각해야 한다
      • 정적인 클래스 의존 관계
        • 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다.
        • 애플리케이션을 실행하지 않아도 분석할 수 있다
      • 동적인 객체 인스턴스 의존 관계
        • 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다
        • 애플리케이션 "실행 시점(런타임)"에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 "의존 관계 주입"이라고 한다
        • 객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다
    • 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.
  • IoC 컨테이너, DI 컨테이너

    • 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것
    • 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라 한다
  • 스프링 컨테이너

    • "ApplicationContext"를 스프링 컨테이너라고 한다

    • 기존에는 개발자가 직접 객체를 생성하고 DI를 했던것을 스프링 컨테이너를 이용해 수행한다.

    • 스프링 컨테이너는 "@Configuration"이 붙은 클래스를 설정(구성)정보로 사용한다. 여기서 "@Bean"이라 적힌 메서드를 모두 호출해 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다.

    • 스프링 빈은 "@Bean"이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다.

    • 스프링 컨테이너를 통해 필요한 스프링 빈(객체)를 찾아야한다. 스프링 빈은 "applicationContext.getBean()" 메서드를 사용해 찾을 수 있다.

    • 결론 : 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용해야 한다


post-custom-banner

0개의 댓글