search

yepdi / TIL

Today I Learn
0 stars 0 forks source link

객체 지향 설계와 스프링 #23

Open yepdi opened 2 years ago

yepdi commented 2 years ago

스프링의 역사

스프링 이전은 EJB(Enterprise Java Beans) 사용. Spring+JPA+ORM 종합 선물 세트 but 복잡하고 어렵다

EJB 컨테이너 -> 스프링 EJB Entity 빈 기술 -> Hibernate. JPA(자바 표준 정의)

JPA는 표준 인터페이스며 JPA 구현체는 Hibernate, EclipseLink 등이 있다

로드 존슨 책 출간 (J2EE Development Without EJB)

스프링은 전통적인 J2EE(EJB)라는 겨울을 넘어 새로운 시작을 뜻.. 😰

스프링 프레임워크 역사

2003 Spring Framework 1.0 - XML 기반 설정 2006 Spring Framework 2.0 - XML 편의 기능 지원 2009 Spring Framework 3.0 - 자바 코드 지원 2013 Spring Framework 4.0 - 자바 8 지원 2014 Spring Boot 1.0 (스프링 설정을 편리하게 해주는) 2017 Spring Framework 5.0, Spring Boot 2.0 - reactive 프로그래밍 지원 (ex. non-blocking) 2020 Spring Fraemwork 5.2, Spring Boot 2.3

스프링 종류

https://spring.io/projects

스프링 프레임워크

스프링 부트

스프링 데이터 : 데이터 CUD 기능 제공 (ex. spring JPA) 스프링 세션 : 세션 기능 편리하게 제공 스프링 시큐리티 : 보안 스프링 Rest Docs : API 문서화 스프링 배치 : batch 처리 특화 스프링 클라우드 : 클라우드 기술 특화

스프링을 만든 이유?

yepdi commented 2 years ago

객체 지향

다형성

yepdi commented 2 years ago

좋은 객체 지향 설계의 5가지 원칙 (SOLID)

문제 상황

MemberRepository memberRepository = new MemoryMemberRepository()

해당 코드는 인터페이스인 MemberRepository와 MemoryMemberRepository 둘 다 의존하는 구조 OCP, DIP 위반하는 코드

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

객체지향 설계와 스프링

다형성 + OCP, DIP를 가능하도록 지원 DI : 의존관계, 의존성 주입. DI 컨테이너 제공 클라이언트 코드의 변경 없이 기능 확장

yepdi commented 2 years ago

객체 지향 원리 적용

IoC , DI 그리고 컨테이너

의존관계 주입 DI(Dependency Injection)

yepdi commented 2 years ago

스프링 컨테이너 생성

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

ApplicationContext는 스프링 컨테이너 이자 인터페이스 스프링 컨테이너는 XML 기반, 애노테이션 기반 자바 설정 클래스도 만들 수 있다

  1. 스프링 컨테이너 생성 : 구성 정보를 지정해줘야 한다 (ex. AppConfig.class )
  2. 스프링 빈 등록 : 스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해서 스프링 빈을 등록한다 (@Bean(name=)으로 다른 이름 설정 가능하다. 이 때 빈 이름은 다른 이름으로 부여하자)
  3. 스프링 빈 의존관계 설정 - 준비
  4. 스프링 빈 의존관계 설정 - 완료 : 스프링 컨테이너는 설정 정보를 참고해서 의존 관계를 주입한다

스프링은 빈을 생성하고 의존관계를 주입하는 단계가 나눠져있다. 그런데 이렇게 자바 코드로 스프링 빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리된다.

BeanFactory 란?

image

ApplicationContext란?

image

BeanDefinition

image
yepdi commented 2 years ago

스프링 컨테이너와 스프링 빈

싱글톤 패턴

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 것 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야한다 

class SingletonService {
    companion object {
        //    1. Static 영역에 객체 instance를 미리 하나 생성해서 올려둔다
        private val instance = SingletonService()
        //    2. 객체 인스턴스가 필요하면 getInstance() 메서드를 통해서만 조회할 수 있다. 같은 인스턴스 반환
        fun getInstance(): SingletonService = instance
    }
    //    3. 딱 1개의 객체 인스턴스만 존재해야 하므로 생성자를 private으로 막아서 외부에 new 키워드로 객체 인스턴스가 생성되는 것을 막는다
    private constructor()

    fun logic() {
        println("싱글톤 객체 로직 호출")
    }
}

싱글톤 패턴을 적용하면 고객의 요청이 올 때마다 객체를 생성하는 것이 아니라 만들어진 객체를 공유해서 효율적으로 사용할 수 있다

문제점

  1. 구현하는 코드 자체가 많이 들어간다
  2. 클라이언트가 구체 클래스를 의존해야한다 -> DIP 위반
  3. 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반 (클라이언트 코드 수정 필요)
  4. 테스트 하기 어렵다
  5. 내부 속성을 변경하거나 초기화 하기 어렵다
  6. private 생성자로 자식 클래스 만들기 어렵다
  7. 유연성이 떨어진다
  8. 안티패턴으로 불리기도 한다

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리

싱글톤 방식의 주의점

객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안된다 즉, 무상태(stateless)로 설계해야 한다

스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다 공유 필드는 조심해야한다. 스프링 빈은 항상 무상태(stateless)로 설계하자 🤭

@Configuration Annotation

        val ac = AnnotationConfigApplicationContext(AppConfig::class.java)
        val bean = ac.getBean(AppConfig::class.java)

        println("bean = ${bean.javaClass}")
//        bean = class core.studyspring.AppConfig$$EnhancerBySpringCGLIB$$4c769945

-> AppConfig는 @Configuration이 적용된 상태이다. 만약 @Configuration이 없다면 bean은 class core.studyspring.AppConfig 로 출력될 것

클래스 명에 xxxCGLIB가 붙으면서 상당히 복잡해진 것을 알 수 있다. 스프링이 CGLIB라는 바이트 코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고 그 다른 클래스를 스프링 빈으로 등록

   @Bean
   fun memberRepository(): MemberRepository {
      if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있다면?) {
         return 스프링 컨테이너에서 찾아서 반환
      } else {
         기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
         return 반환
      }
   }

정리

@Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다 스프링 정보는 항상 @Configuration 을 사용하자

yepdi commented 2 years ago

컴포넌트 스캔과 의존관계 자동 주입

@Configuration
@ComponentScan(
    basePackages = ["core.studyspring"],
    excludeFilters = [ComponentScan.Filter(type = FilterType.ANNOTATION, classes = arrayOf(Configuration::class))]
    // 테스트용
)
class AutoAppConfig {

}

ComponentScan 과 Bean 관계

  1. @ComponentScan @ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다 (싱글톤) 빈 기본 이름은 클래스명을 사용한다. 맨 앞글자만 소문자로 사용 스프링 빈의 이름을 직접 지정하고 싶으면 @Component(“…”) 와 같이 직접 지정

  2. @Autoriwred 의존관계 자동 주입 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입 기본 조회 전략은 타입이 같은 빈을 찾아서 주입

탐색 위치와 기본 스캔 대상

지정하지 않으면 @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다

권장 방법 : 패키지 위치를 지정하지 않고, 설정 정보 클래스의 위치를 프로젝트 최상단에 둔다 

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
        @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {

컴포넌트 스캔 기본 대상

애노테이션은 상속 관계가 없다. 자바 언어에서 지원하는 기능이 아니라 스프링이 지원하는 기능 useDefaultFilters 기본이 켜져있는데 끄면 기본 스캔 대상들이 제외

필터

@Target(AnnotationTarget.CLASS)
@Retention(AnnotationRetention.RUNTIME)
@MustBeDocumented
annotation class MyExcludeComponent ()

@Configuration
    @ComponentScan(includeFilters = [ComponentScan.Filter(classes = arrayOf(MyIncludeComponent::class))])
    @ComponentScan(excludeFilters = [ComponentScan.Filter(type = FilterType.ANNOTATION, classes = arrayOf(MyExcludeComponent::class))])
    class ComponentFilterAppConfig {
        companion object {

        }
    }

스프링 부트는 컴포넌트 스캔을 기본으로 제공하는데 개인적으로 옵션을 변경하면서 사용하기 보다는 스프링의 기본 설정에 최대한 맞추어 사용하는 것을 권장하고 선호하는 편이다

중복 등록과 충돌

컴포넌트 스캔에서 같은 빈 이름을 등록하면?

현실은 개발자 의도적으로 설정해서 이런 결과가 만들어지기보다는 여러 설정이 꼬여서 이런 결과가 만들어지는 경우가 대부분이다 정말 잡기 어려운 버그가 만들어진다. 항상 잡기 어려운 버그는 애매한 버그다

스프링에서는 자동빈과 수동빈 충돌시 스프링 부트 에러 발생

The bean 'memoryMemberRepository', defined in class path resource [core/studyspring/AutoAppConfig.class], could not be registered. A bean with that name has already been defined in file [/Users/user/study/study-spring/build/classes/kotlin/main/core/studyspring/member/MemoryMemberRepository.class] and overriding is disabled.
yepdi commented 2 years ago

다양한 의존관계 주입 방법 - 1

의존관계 주입 방법

생성자 주입

생성자에 @Autowired keyword 를 붙여주고 private final MemberRepository memberRepository; 생성자에는 값을 다 채워넣어야한다

생성자가 딱 1개만 있으면 @Autowired 를 생략해도 자동 주입이 된다 생성자 주입은 bean을 등록하고 의존관계 주입도 함께 일어난다

수정자 주입(setter)

필드 주입

일반메서드 주입

    @Autowired
    fun init(memberRepository: MemberRepository, discountPolicy: DiscountPolicy) {
        this.memberRepository = memberRepository
        this.discountPolicy = discountPolicy
    }

의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작한다. 스프링 빈이 아닌 클래스에서 @Autowired 코드를 적용해도 아무 기능도 동작하지 않는다

옵션 처리

주입할 스프링 빈이 없어도 동작해야할 때가 있다 @Autowired만 사용하면 required 옵션의 기본값이 true 로 되어 있어서 자동 주입 대상이 없으면 오류가 발생

class AutowiredTest {

    @Test
    fun autowiredOption() {
        val ac = AnnotationConfigApplicationContext(TestBean::class.java)
    }

    class TestBean {
        companion object {
            @Autowired(required = false) // 의존 관계가 없으면 메서드 자체가 호출되지 않는다
//            @Autowired // member가 spring bean이 아니기 때문에 찾을 수 없다
            fun setNoBean1(noBean1: Member) {
                println("noBean1 = $noBean1")
            }

            @Autowired
            fun setNoBean2(@Nullable noBean1: Member) {
                println("noBean2 = $noBean1")
            }

            @Autowired
            fun setNoBean3(noBean1: Optional<Member>) {
                println("noBean3 = $noBean1")
            }
        }
    }
}

@Nullable, Optional은 스프링 전반에 걸쳐서 지원된다. 생성자 자동 주입에서 특정 필드에만 사용해도 된다

생성자 주입을 선택해라

과거에는 수정자 주입과 필드 주입을 많이 사용했지만, 최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장한다

val orderService = OrderServiceImpl()
        // 의존관계 주입 : NPE 발생 의존관계가 눈에 보이지 않는다

생성자 주입 방식을 선택하는 이유는 프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법 기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면 된다. 생성자 주입과 수정자 주입을 동시에 사용할 수 있다 항상 생성자 주입을 선택해라! 그리고 가끔 옵션이 필요하면 수정자 주입을 선택해라. 필드 주입은 사용하지 않는게 좋다

롬복과 최신 트랜드

대부분이 불변이고 생성자에 final 키워드를 사용하게 된다 생성자와 주입받는 값을 코드로 만들어야한다 필드 주입처럼 좀 편리하게 사용하는 방법은 없을까?

@RequiredArgsConstructor 생성자와 final 을 사용

롬복 라이브러리가 제공하는 @RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드들을 모아서 생성자를 자동으로 만들어준다 롬복이 자바의 애노테이션 프로세서라는 기능을 이용해서 컴파일 시점에 생성자 코드를 자동으로 생성해준다

생성자를 딱 1개 두고 @Autowired를 생략하는 방법을 주로 사용한다

yepdi commented 2 years ago

다양한 의존관계 주입방법 - 2

조회 빈이 2개 이상 일 때

타입으로 조회하기때문에 ac.getBean(DiscountPolicy::class) fixDiscountPolicy, RateDiscountPolicy 둘다 DiscountPolicy 타입이기 때문에 다음과 같은 에러가 발생한다

No qualifying bean of type 'core.studyspring.discount.DiscountPolicy' available: expected single matching bean but found 2: fixDiscountPolicy,rateDiscountPolicy

빈이 2개가 발견됨. 하위 타입으로 지정할 수 있으나 하위타입으로 지정하는 것은 DIP 위배. 유연성이 떨어짐.

Autowired Qualifier Primary

조회 대상 빈이 2개 이상일 때 해결 방법

  1. @Autowired 필드 명 매칭
  2. @Qualifier + @Qualifier 끼리 매칭 -> 빈 이름 매칭
  3. @Primary 사용
  1. 타입 매칭
  2. 타입 매칭의 결과가 2개 이상일 때 필드 명(파라미터 명)으로 빈 이름 매칭

추가 구문자로 붙여주는 방법. 주입시 추가적인 방법을 제공하는 것. @Qualifier(“mainDiscountPolicy”) 를 못찾으면 어떻게 될까?
mainDiscountPolicy 라는 이름의 스프링 빈을 추가로 찾는다.

  1. Qualifier 끼리 매칭
  2. 빈 이름 매칭
  3. NoSuchBeanDefinitionException 예외 발생

코드에서 자주 사용하는 메인 데이터베이스의 커넥션을 획득하는 스프링 빈이 있고, 코드에서 특별한 기능으로 가끔 사용하는 서브 데이터베이스의 커넥션을 획득하는 스프링 빈이 있다.

메인 데이터베이스의 커넥션을 획득하는 스프링 빈은 @Primary 를 적용해서 조회하는 곳에서 @Qualifier 지정 없이 편리하게 조회하고, 서브 데이터베이스 커넥션 빈을 획득할 때는 @Qualifier 를 지정해서 명시적으로 획득 하는 방식으로 사용하면 코드를 깔끔하게 유지할 수 있다. 물론 이때 메인 데이터베이스의 스프링 빈을 등록할 때 @Qualifier 를 지정해주는 것은 상관없다.

애노테이션 직접 만들기

@Qualifier(“mainDiscountPolicy”) 컴파일시 타입 체크가 안된다 직접 애노테이션으로 컴파일시 확인가능

@Target(ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Qualifier("mainDiscountPolicy")
annotation class MainDiscountPolicy(

애노테이션에는 상속이라는 개념이 없다. 이렇게 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능이다. @Qulifier 뿐만 아니라 다른 애노테이션들도 함께 조합해서 사용할 수 있다. 단적으로 @Autowired도 재정의 할 수 있다. 물론 스프링이 제공하는 기능을 뚜렷한 목적 없이 무분별하게 재정의 하는 것은 유지보수에 더 혼란만 가중할 수 있다.

조회한 빈이 모두 필요할 때

의도적으로 정말 해당 타입의 스프링 빈이 다 필요한 경우도 있음 ex. 할인 서비스를 제공하는데, 클라이언트가 할인의 종류(rate, fix)를 선택할 수 있다고 가정해보자. 스프링을 사용하면 소위 말하는 전략 패턴(Strategy Pattern)을 매우 간단하게 구현할 수 있다. 

      val ac = AnnotationConfigApplicationContext(AutoAppConfig::class.java, DiscountService::class.java)
      val discountService = ac.getBean(DiscountService::class.java)

class DiscountService {
        fun discount(member: Member, price: Int, discountCode: String): Int {
            val discountPolicy = policyMap.get(discountCode)
            return discountPolicy?.discount(member, price)!!
        }

        var policyMap: Map<String, DiscountPolicy>
        var policies : List<DiscountPolicy>

        @Autowired
        constructor(policyMap: Map<String, DiscountPolicy>, policies : List<DiscountPolicy>) {
            this.policies = policies
            this.policyMap = policyMap
            println("policies $policies")
            println("policyMap $policyMap")
        }
    }

수동 빈 등록은 언제 사용하면 좋은가?

결론부터 이야기하면, 스프링이 나오고 시간이 갈 수록 점점 자동을 선호하는 추세다.

애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해서 딱! 설정 정보에 바로 나타나게 하는 것이 유지보수 하기 좋다.

편리한 자동 기능을 기본으로 사용하자
 직접 등록하는 기술 지원 객체는 수동 등록
 다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자

yepdi commented 2 years ago

빈 생명주기 콜백

yepdi commented 2 years ago

빈 스코프 - 1

yepdi commented 2 years ago

빈스코프 - 2

웹스코프

웹 스코프 예제

@Controller
class LogDemoController(
    val logDemoService: LogDemoService,
    val myLogger: MyLogger
) {

    @RequestMapping("log-demo")
    @ResponseBody // responseBody면 문자열 그대로 내보낼 수 있다
    fun logDemo(request: HttpServletRequest): String {
        val requestUrl = request.requestURL.toString()
        myLogger.setRequestUrl(requestUrl)

        myLogger.log("controller test")
        logDemoService.logic("testId")
        return "OK"
    }
}

@Component
@Scope(value = "request")
class MyLogger {
    private lateinit var uuid: String
    private lateinit var requestUrl: String

    fun setRequestUrl(requestUrl: String) {
        this.requestUrl = requestUrl
    }

    fun log(message: String) {
        println("[$uuid][$requestUrl] $message")
    }

    @PostConstruct
    fun init() {
        // 빈이 생성되는 시점에 uuid 생성하고 저장
        this.uuid = UUID.randomUUID().toString()
        println("[$uuid] request scope bean create: $this")
    }

    @PreDestroy
    fun close() {
        println("[$uuid] request scope bean close: $this")
    }
}

웹 스코프 오류 해결방안 (1) ObjectProvider 사용

@Controller
class LogDemoController(
    val logDemoService: LogDemoService,
    val myLoggerProvider: ObjectProvider<MyLogger>
) {
    @RequestMapping("log-demo")
    @ResponseBody // responseBody면 문자열 그대로 내보낼 수 있다
    fun logDemo(request: HttpServletRequest): String {
        val myLogger = myLoggerProvider.getObject()
        val requestUrl = request.requestURL.toString()
        println("myLogger = ${myLogger.javaClass}")
        myLogger.setRequestUrl(requestUrl)

        myLogger.log("controller test")
        logDemoService.logic("testId")
        return "OK"
    }
}

웹 스코프 오류 해결방안 (2) 프록시 사용

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
// HTTP 요청당 하나씩 생성되고 HTTP 요청이 끝나는 시점에 소멸됨
// Proxy 사용시 이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.
class MyLogger {
    private lateinit var uuid: String
    private lateinit var requestUrl: String

    fun setRequestUrl(requestUrl: String) {
        this.requestUrl = requestUrl
    }

    fun log(message: String) {
        println("[$uuid][$requestUrl] $message")
    }

    @PostConstruct
    fun init() {
        // 빈이 생성되는 시점에 uuid 생성하고 저장
        this.uuid = UUID.randomUUID().toString()
        println("[$uuid] request scope bean create: $this")
    }

    @PreDestroy
    fun close() {
        println("[$uuid] request scope bean close: $this")
    }
}

프록시 동작 원리

myLogger = class hello.core.common.MyLogger$$EnhancerBySpringCGLIB$$b68b726d

프록시 특징