이번 포스팅 주제는 개인적으로 생각하는 Spring 의 철학입니다. 들어가기 앞서 SOLID 원칙에 대해 살짝 알아보고 가봅시다. SRP (Single Responsibility Principle)단일 책임 원칙입니다. 하나의 클래스는 하나의 책임만 가져야 한다. 다른 말로는 클래스가 변경되는 이유는 한가지여야 한다 입니다. OCP (Open / Close Principle)개방 폐쇄 원칙입니다. 풀어서 보면, 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 입니다. 좀더 쉽게 보자면, 확장에는 열려있다. -> 애플리케이션의 요구 사항이 변경될 때, 이 변경에 맞게 새로운 동작을 추가해 모듈을 확장할 수 있다. 수정에 닫혀있다. -> 기존의 소스 코드를 수정하지 않아도 모듈의 기능을 ..

@Configuration 은 스프링 컨테이너에 스프링 빈을 등록할 수 있도록 해주는 어노테이션이다. @Configuration 이 적용된 클래스 내부에 다수의 @Bean 이 적용된 메서드가 있으면 스프링 빈으로 등록해준다. @Bean 이 적용된 메서드가 하는 역할은 반환되는 객체를 해당 메서드의 이름을 가진 스프링 빈으로 등록한다. @Bean 은 스프링 빈으로 등록되는 클래스에 작성하여도 동작한다. (@Component 적용된 클래스 내부에 작성) 본격적으로 이번 포스팅 주제인.. @Configuration 어노테이션의 이해도를 높여보자. @Configuration public class AppConfig { @Bean public MyBean myBean() { return new MyBean(); ..

https://docs.spring.io/spring-framework/reference/integration/scheduling.html Task Execution and Scheduling :: Spring Framework All Spring cron expressions have to conform to the same format, whether you are using them in @Scheduled annotations, task:scheduled-tasks elements, or someplace else. A well-formed cron expression, such as * * * * * *, consists of six space-separated time docs.spring.i..

소프트웨어 개발에서 변경이 필요할 때... 변경 지점이 하나가 될 수 있도록 설계하고 개발해야한다.. 핵심 기능과 부가 기능을 분리하여.. 부가 기능을 어느 한 군데서만 관리하면 되도록 해보자.. 이를 위한.. 관점 지향 프로그래밍 AOP (Aspect Oriented Programming) AOP는 OOP를 대체하기 위해 나온 프로그래밍 방식이 아니다. 횡단 관심사를 처리하기 어려운 OOP의 부족한 부분을 보조하기 위해 개발되었다. AOP 적용 방법은 총 3가지가 있다. 1. 컴파일 시점에 부가 기능 적용(원본 코드 조작, Weaving) 2. 클래스 로딩 시점에 부가 기능 적용(.class 파일 조작) 3. 런타임 시점에 부가 기능 적용(프록시 방식) 스프링은 위 3가지 방식 중.. 프록시 방식의 A..

지난 포스팅에서는 빈 후 처리기(BeanPostProcessor) 인터페이스를 구현하여.. 프록시를 스프링 빈 저장소에 원본 객체 대신 집어 넣을 수 있었다. (개발자의 개발 대상 : Advisor, BeanPostProcessor) 스프링은.. 역시 개발자를 편하게 해준다.. 스프링은.. 이미.. 프록시를 생성하기 위한 빈 후처리기를 만들어서 제공한다. -> AnnotationAwareAspectJAutoProxyCreator 이다. -> 따라서, 개발자는 Advisor만 개발하면 된다. 이를 위해서.. 아래 라이브러리를 추가 해주자. implementation 'org.springframework.boot:spring-boot-starter-aop' 해당 라이브러리를 추가하면 스프링 부트가 AOP 관..

직전 포스팅에서.. ProxyFactory를 사용하여 프록시 객체를 생성하고 적용하는 방법의 문제점을 다시 적어보겠다.. 1. 수동 빈 등록 시, @Configuration에서 ProxyFactory를 통해 일일이 프록시를 생성하고 리턴 해줘야함.. 2. 컴포넌트 스캔을 통해 자동 빈 등록을 사용하는 클래스는 프록시를 적용할 수 없음 -> 스프링 컨테이너에 타겟 객체가 직접 등록이 되어버려서 개발자가 손쓸수가 없는 상황 이 문제점은.. 스프링에서 제공하는.. 빈 후 처리기(BeanPostProcessor) 로 해결할 수 있다. 빈 후 처리기는.. 스프링이 빈 저장소에 등록할 목적으로 생성한 객체를 빈 저장소에 등록하기 직전에 조작하고 싶을 때 사용한다. -> 다른 객체로 바꿔치기 가능..(프록시로..) ..

앞선 포스팅에서 JDK 동적 프록시 기술과 CGLIB 동적 프록시 기술에 대하여 알아 봤다. 두 기술은 동일하게 프록시라는 기술을 도입하게 해주지만.. JDK 동적 프록시 기술은 인터페이스가 있어야 하고.. CGLIB는 구체 클래스로 프록시를 만들어 낸다.. 그래서 사용법이 달랐다.. 개발자는 편해지고 싶다.. 인터페이스가 있다면 JDK 동적 프록시가 적용되고 구체클래스만 있다면 CGLIB가 적용되게 알아서 해주는건 없나? -> 스프링은 역시 이미 제공하고 있다. 바로 프록시 팩토리 ! 프록시 팩토리에 대해 알아보자.. 선 요약 Advice : 프록시 로직이 들어가고 실제 target 객체 메서드를 호출 Pointcut : 특정 조건이 맞을 때만 프록시가 적용되도록 해줌 프록시에 추가할 로직은 기존에....

이번 포스팅에서는 CGLIB를 통한 동적 프록시 기술에 대해 알아보겠다. JDK 동적 프록시 기술에서는 인터페이스가 있어야 동적으로 프록시를 만들 수 있는 제약 사항이 있었다.. 이를 위한.. CGLIB 동적 프록시 기술!! -> 구체 클래스를 상속해서 프록시를 만든다. CGLIB는 바이트 코드를 조작하여 동적으로 클래스를 생성하는 기술을 제공하는 라이브러리이다. CGLIB는 원래 외부 라이브러리 이지만.. 스프링 프레임워크가 스프링 내부 소스 코드에 포함하여.. 따로 라이브러리 추가 없이 사용 가능 하다. JDK 동적 프록시의 InvocationHandler 인터페이스와 비슷하게.. CGLIB 동적 프록시는 MethodInterceptor 인터페이스를 제공한다. 역시.. reflection 기술을 사용..