정리

• 스프링: 자바 언어 기반의 객체지향 웹개발 프레임워크
• 스프링 부트: 스프링을 편리하게 사용할 수 있도록 지원하는 프레임워크
• 객체 지향의 특징: 추상화, 캡슐화, 상속, 다형성
  • 그 중 다형성이 중요. 역할과 구현으로 구분
  • 자동차라는 역할이 있으면 구현체로 K3, 아반떼, 테슬라 모델 3 등이 있음
  • 자동차가 바뀐다고 운전면허를 새로 딸 필요 없음. 역할이 동일하니 바로 운전 가능. 클라이언트는 자동차가 어떻게 구현되어있는지는 중요하지 않음. 자동차라는 인터페이스만 중요. 새로운 자동차가 나와도 운전자가 새로 배우지 않아도 됨
  • 역할과 구현으로 구분하면 부품을 갈아 끼우듯이 서버의 구현을 유연하게 변경 가능
• SOLID: 좋은 객체지향 설계를 위한 원칙
  • SPR(Single Responsibility Principle): 단일 책임 원칙
    • 한 클래스는 하나의 책임만을 가짐. 변경에 따른 파급 효과가 적어야함.
  • OCP(Open / Closed Principle): 개방 / 폐쇄 원칙
    • (새로운 구현체로의) 확장에는 열려있고, (기존 코드의) 변경에는 닫혀있어야함.
      • 구현체를 새로운 것으로 변경하여도 기존 코드는 그대로여야함.
      • 이게 가능하려면 구현체에 의존하면 안되고 인터페이스에 의존해야함. 즉 역할과 구현을 분리하는 다형성을 활용해야함.
      • 뿐만아니라 코드가 인터페이스에 의존하기 때문에 실제 구현체(객체)를 생성 및 연결시켜주는 별도의 조립 및 설정자가 필요 ⇒ 스프링이 이부분을 해줌
  • LSP(Liskov Substitution Princile): 리스코프 치환 원칙
    • 하위 타입의 인스턴스로 객체를 변경해도 인터페이스에서 정의한 기능이 달라지면 안됨.
  • ISP (Interface Segregation Principle): 인터페이스 분리 원칙
    • 하나의 범용 인스턴스보다 여러 개의 인터페이스로 분리하는 것이 더 명확하고 대체 가능성이 높아짐
    • ex. 자동차라는 범용 인터페이스보다 운전 인터페이스와 정비 인터페이스로 분리하는 것이 좋음
  • DIP (Dependency Inversion Principle): 의존 관계 역전 원칙
    • 구현체에 의존하지 않고 추상화(=역할)에 의존해야함
    • 순수 자바 언어로는 클라이언트가 구현 클래스를 직접 선택하기 때문에 인터페이스와 구현 클래스를 동시에 의존함. 스프링이 DI를 통해 이 문제를 해결해줌.
• 객체 지향 설계와 스프링
  • 순수 자바 언어로는 OCP와 DIP를 지키기 힘듦.
  • 이를 위해 스프링이 등장. DI (Dependency Injection) 개념과 DI 컨테이너를 제공하여 다형성과 OCP, DIP를 가능하게 함 ⇒ 클라이언트 코드의 변경없이 기능을 확장하도록 도와줌.
• AppConfig: 애플리케이션의 전체 동작 방식을 구성하기 위해 구현 객체를 생성하고 연결하는 책임을 가지는 별도 설정 클래스.
  • 예시
• IoC (Inversion of Control): 제어의 역전
  • 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고 실행함
  • 반면 AppConfig가 등장한 이후 구현 객체는 자신의 로직을 실행하는 역할만 담당하고 제어의 흐름은 App Config가 가져감
  • 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것이 제어의 역전(IoC)임
• DI (Dependency Injection): 의존 관계 주입
  • 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존 관계가 연결되는 것을 의미
  • 구현체는 인터페이스에만 의존. 실제 어떤 구현 객체가 사용될지 모름.
  • 정적인 클래스 의존 관계와 동적인 객체(인스턴스) 의존 관계로 분리해서 생각해야함
    • 정적인 클래스 의존 관계는 import만 보고 파악 가능
    • 동적인 객체(인스턴스) 의존 관계는 실행 시점에 연결
  • DI를 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 타입 인스턴스 변경 가능
  • DI를 사용하면 클래스 의존 관계를 변경하지 않고, 동적인 객체 인스턴스 의존 관계를 변경 가능
• DI 컨테이너 / IoC 컨테이너
  • AppConfig처럼 객체를 생성하고 관리하면서 의존 관계를 연결
• 스프링 컨테이너
  • ApplicationContext: 스프링 컨테이너
  • 스프링 컨테이너는 @Configuration 이 붙은 AppConfig를 설정 정보로 사용.
  • @Bean 이라고 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록. 스프링 컨테이너에 등록된 객체를 스프링빈이라고함.
  • 예시 코드
• 스프링 컨테이너와 스프링빈

  • 스프링 컨테이너 생성

    ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
    

    • 스프링 컨테이너(ApplicationContext)는 XML 혹은 애노테이션 기반 클래스로 만들 수 있음
    • AnnotationConfigApplicationContext는 ApplicationContext(인터페이스)의 구현체임

  • 스프링 빈 등록

    • 스프링 컨테이너는 파라미터로 넘어온 설정 클래스(AppConfig)를 사용해서 스프링빈을 등록
    • 빈 이름의 디폴트 값은 메서드 이름. @Bean(name=”orderService”)로 직접 설정가능

  • 스프링 빈 의존 관계 설정

    • 설정 정보를 참고해서 의존 관계를 주입(DI)함.
    • 싱글톤 컨테이너로, 단순히 자바 코드를 호출하는 것과 차이가 있음

  • 스프링 빈 조회

    • ac.getBean(빈이름, 타입) / ac.getBean(타입)
    • 동일한 타입이 둘 이상인 경우 중복 에러 발생
      • 부모 타입으로 조회 시 자식이 둘 이상 있으면 중복 에러 발생
    • getBeansOfType(타입)으로 여러 개 조회 가능
• BeanFactory와 ApplicationContext
  • BeanFactory ← ApplicationContext ← AnnotationConfigApplicationContext (구현체)
  • BeanFactory: 스프링 컨테이너의 최상위 인터페이스로 스프링 빈을 관리하고 조회. getBean 제공
  • ApplicationContext: 빈 관리 및 조회 기능 뿐만 아니라 여러 부가 기능 제공
    • 메세지 소스를 활용한 국제화, 환경 변수, 애플리케이션 이벤트(발행/구독), 리소스(파일 등) 조회 기능 제공
    • 사진
  • 스프링 컨테이너는 자바 코드(.class), XML(.xml), Groovy(.xxx)를 지원
    • 사진
• 싱글톤 컨테이너
  • 웹 애플리케이션과 싱글톤
    • 고객 트래픽이 초당 100일 때 초당 100개의 객체가 생성되고 소멸되는 문제를 막기 위해 싱글톤 패턴 사용
  • 싱글톤
    • 예시
    • 싱글톤의 문제점
      1. 싱글톤 패턴을 구현하는 코드 자체가 많이 들어갑니다.
      2. 의존 관계상 클라이언트가 구체 클래스에 의존합니다. 결국 DIP를 위반합니다.
      3. 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높습니다.
      4. 테스크 코드 작성이 어렵습니다.
      5. 내부 속성을 변경하거나 초기화하기 어렵습니다.
      6. private 생성자로 자식 클래스를 만들기 어렵습니다.
    • ⇒ 유연성이 떨어져서 안티패턴으로 불림
  • 싱글톤 컨테이너
  • 싱글톤 방식의 주의점
  • @Configuration과 싱글톤
• 컴포넌트 스캔
• 의존 관계 자동 주입
• 생성자 주입
• 의존 관계에 조회되는 빈이 2개 이상인 경우
• 조회한 빈이 모두 필요한 경우