나의 구름낀 조각들

스프링 부트 AOP(Aspect-Oriented Programming) 완벽 가이드: 개념, 프록시 동작 원리 및 실무 예제

J-Mandu — Fri, 3 Jul 2026 10:15:17 +0900

1. AOP(관점 지향 프로그래밍)의 등장 배경과 필요성

자바(Java) 웹 백엔드 개발을 위해 스프링(Spring) 프레임워크를 학습하다 보면 DI(의존성 주입)와 함께 가장 중요하게 다루어지는 개념이 바로 AOP(Aspect-Oriented Programming, 관점 지향 프로그래밍)입니다.

객체 지향 프로그래밍(OOP)은 애플리케이션을 여러 개의 독립적인 객체로 나누고, 이들의 상호작용으로 로직을 구성합니다. 덕분에 비즈니스 로직의 모듈화와 재사용성이 크게 향상되었습니다. 하지만 애플리케이션의 규모가 커지면서 OOP만으로는 해결하기 어려운 문제에 직면하게 됩니다.

바로 흩어진 관심사(Cross-cutting Concerns)의 문제입니다. 게시판 서비스를 예로 들어보겠습니다. '게시글 작성', '게시글 수정', '회원 가입'이라는 핵심 비즈니스 로직(Core Concerns)이 있습니다. 그런데 이 모든 로직 전후에 실행 시간을 측정하는 로깅(Logging) 처리, 데이터베이스 트랜잭션(Transaction) 처리, 보안 인가(Security) 과정이 공통으로 필요하다면 어떻게 될까요?

모든 클래스의 메서드마다 동일한 로깅 코드와 트랜잭션 코드를 복사해서 붙여넣어야 합니다. 이는 코드의 중복을 낳고, 훗날 수정이 필요할 때 수백 개의 파일을 일일이 고쳐야 하는 유지보수의 지옥을 만들어냅니다.

AOP는 바로 이 지점에서 구원투수로 등장합니다. 핵심 비즈니스 로직에서 공통으로 사용되는 부가 기능(관심사)을 별도의 모듈(Aspect)로 분리해 내고, 원하는 곳에 동적으로 적용하는 기술입니다. 즉, AOP는 OOP를 배척하는 것이 아니라, OOP가 더욱 객체 지향적인 원칙(특히 단일 책임 원칙)을 잘 지킬 수 있도록 돕는 완벽한 파트너입니다.

2. AOP를 정복하기 위한 핵심 용어 (Terminology)

AOP 관련 공식 문서나 기술 블로그를 읽다 보면 난해한 용어들 때문에 좌절하기 쉽습니다. 실무에 AOP를 적용하기 위해 반드시 알아야 할 핵심 용어 6가지를 쉽게 풀어 설명해 드립니다.

2.1. Aspect (애스펙트)

정의: 공통으로 적용될 부가 기능(Advice)과 그 기능이 어디에 적용될지(Pointcut)를 하나로 묶은 모듈입니다.
비유: '로깅', '트랜잭션 관리' 등 흩어진 관심사를 하나의 클래스로 깔끔하게 모아둔 상자라고 생각하면 됩니다.

2.2. Target (타겟)

정의: Aspect가 적용되는 실제 비즈니스 로직을 가진 객체입니다.
설명: 우리가 작성한 UserService, BoardService 같은 클래스들이 타겟이 됩니다.

2.3. Advice (어드바이스)

정의: 타겟에 제공할 실질적인 부가 기능 구현체(코드)입니다.
종류: 언제 실행될 것인지에 따라 @Before(메서드 실행 전), @After(실행 후), @Around(실행 전후 모두, 가장 강력함), @AfterReturning(정상 반환 후), @AfterThrowing(예외 발생 시)으로 나뉩니다.

2.4. JoinPoint (조인포인트)

정의: Advice가 적용될 수 있는 애플리케이션 실행 흐름 상의 합류 지점입니다.
특징: 이론적으로는 생성자 호출 시, 필드 값 변경 시 등 다양하지만, 스프링 AOP는 오직 '메서드 실행 시점'만을 JoinPoint로 허용합니다.

2.5. Pointcut (포인트컷)

정의: 무수히 많은 JoinPoint 중에서, 실제로 Advice를 적용할 타겟 메서드를 선별하는 정규 표현식 또는 조건입니다.
비유: "com.example.service 패키지 밑에 있는 클래스 중 이름이 'get'으로 시작하는 메서드에만 적용해라!"라고 타겟팅을 하는 필터 역할입니다.

2.6. Weaving (위빙)

정의: Pointcut으로 결정된 타겟의 JoinPoint에 실제 Advice(부가 기능)를 끼워 넣는 과정입니다.

3. 스프링 AOP의 심장: 프록시(Proxy) 동작 원리

AOP를 구현하는 방법은 컴파일 타임에 코드를 삽입하거나, 클래스가 로드될 때 바이트코드를 조작하는 등 여러 방식(AspectJ)이 있습니다. 하지만 스프링 AOP는 '프록시(Proxy) 패턴'을 기반으로 동작하는 런타임 위빙(Runtime Weaving) 방식을 채택하고 있습니다. 이 동작 원리를 이해하는 것은 기술 면접에서도 매우 중요합니다.

스프링 프레임워크가 부팅되면서 빈(Bean)들을 생성할 때, 대상 빈이 AOP 적용 대상(Target)이라면 스프링은 실제 객체를 그대로 스프링 컨테이너에 올리지 않습니다. 대신, 실제 객체를 감싸고 있는 가짜 객체(Proxy 객체)를 동적으로 생성하여 빈으로 등록합니다.

클라이언트(컨트롤러 등)가 서비스의 메서드를 호출하면, 실제로는 다음의 흐름이 발생합니다.

클라이언트가 프록시 객체의 메서드를 호출합니다.
프록시 객체는 AOP에 정의된 부가 기능(Advice, 예: 로깅 시작)을 먼저 실행합니다.
프록시가 실제 객체(Target)의 비즈니스 로직을 대신 호출(위임)합니다.
실제 로직 실행이 끝나면, 프록시가 다시 나머지 부가 기능(예: 실행 시간 계산 후 로깅 끝)을 마무리하고 클라이언트에게 결과를 반환합니다.

이러한 프록시 기반 동작 덕분에 우리는 기존 비즈니스 로직 코드를 단 한 줄도 수정하지 않고 부가 기능을 마음껏 추가하고 뺄 수 있는 것입니다. (참고로 스프링 부트 환경에서는 기본적으로 CGLIB라는 라이브러리를 사용하여 클래스 기반의 프록시를 생성합니다.)

4. 실무 완벽 적용: 커스텀 어노테이션 기반 AOP 구현 예제

단순히 패키지 경로를 기준으로 AOP를 적용(Pointcut 표현식)하면, 원치 않는 메서드까지 적용되거나 패키지 구조가 변경되었을 때 에러가 발생하기 쉽습니다. 따라서 실무에서는 개발자가 직접 만든 커스텀 어노테이션을 부착한 메서드에만 AOP가 동작하도록 구현하는 방식을 널리 사용합니다.

대표적인 예제인 'API 실행 시간 측정 로직'을 만들어 보겠습니다.

4.1. 의존성 (Dependency) 추가

스프링 부트 프로젝트의 build.gradle에 AOP 스타터 의존성을 추가합니다.

Gradle

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-aop'
}

4.2. 커스텀 어노테이션 생성 (@Timer)

시간 측정을 원하는 메서드에 붙일 용도로 활용할 어노테이션을 하나 생성합니다.

Java

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target({ElementType.METHOD}) // 메서드에만 적용 가능
@Retention(RetentionPolicy.RUNTIME) // 런타임까지 유지
public @interface Timer {
    // 내부 로직은 비워둡니다. 일종의 '마커(Marker)' 역할입니다.
}

4.3. Aspect 클래스 구현

실제 시간을 측정하고 로그를 남기는 부가 기능(Advice) 클래스를 작성합니다. @Aspect와 빈 등록을 위한 @Component가 필수입니다.

Java

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;
import org.springframework.util.StopWatch;

@Aspect
@Component
public class TimerAspect {

    private static final Logger log = LoggerFactory.getLogger(TimerAspect.class);

    // 우리가 만든 @Timer 어노테이션이 붙은 메서드만 Pointcut으로 지정합니다.
    @Around("@annotation(com.example.demo.annotation.Timer)")
    public Object measureTime(ProceedingJoinPoint joinPoint) throws Throwable {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        // 1. Target의 실제 비즈니스 로직 실행 (핵심)
        Object result = joinPoint.proceed();

        stopWatch.stop();
        
        // 2. 부가 기능 수행 (실행 시간 로깅)
        String methodName = joinPoint.getSignature().getName();
        log.info("[Timer AOP] {} 메서드 실행 시간: {} ms", methodName, stopWatch.getTotalTimeMillis());

        return result;
    }
}

여기서 핵심은 @Around 내부의 joinPoint.proceed() 입니다. 이 코드를 기점으로 위쪽이 '메서드 실행 전(Before)', 아래쪽이 '메서드 실행 후(After)'에 동작할 코드가 됩니다.

4.4. 서비스에 적용하기

이제 핵심 비즈니스 로직이 있는 서비스 계층에서 앞서 만든 @Timer 어노테이션만 붙여주면 끝입니다.

Java

import com.example.demo.annotation.Timer;
import org.springframework.stereotype.Service;

@Service
public class UserService {

    @Timer
    public void createUser() throws InterruptedException {
        // 복잡한 비즈니스 로직이 있다고 가정
        System.out.println("회원 가입 로직 실행 중...");
        Thread.sleep(1500); // 1.5초 소요 가정
    }
}

이제 createUser() 메서드가 호출될 때마다 스프링 프록시가 개입하여 자동으로 실행 시간을 측정하고 콘솔에 로그를 남겨줍니다. 서비스 로직 안에는 로깅 코드가 전혀 섞이지 않은 깔끔한 상태를 유지하게 됩니다.

5. 스프링 AOP 사용 시 치명적인 주의사항: 내부 호출 (Self-Invocation)

스프링 AOP를 실무에 적용할 때 주니어 개발자들이 가장 많이 겪는 장애 포인트가 있습니다. 바로 '같은 클래스 내부에서의 메서드 호출 시에는 AOP가 동작하지 않는다'는 점입니다.

앞서 스프링 AOP는 '프록시(Proxy)' 객체를 통해 동작한다고 설명했습니다. 외부 컨트롤러에서 서비스 메서드를 호출할 때는 프록시를 거치기 때문에 AOP가 정상 작동합니다. 하지만, 서비스 클래스 내부에서 자신의 다른 메서드를 직접 호출할 때(this.method())는 프록시를 거치지 않고 실제 객체의 내부 코드를 직접 실행해버리기 때문에 AOP(부가 기능)가 발동하지 않습니다.

따라서 트랜잭션(@Transactional 역시 AOP 기반)이나 캐시 등을 적용한 메서드를 설계할 때는, 외부에서 직접 호출되도록 클래스를 분리하거나 구조를 재설계해야 한다는 점을 반드시 명심하시기 바랍니다.

6. 마치며

이번 포스팅에서는 자바 스프링의 핵심 철학인 AOP의 기본 개념부터 핵심 용어, 프록시 동작 원리, 그리고 실무에서 강력하게 활용되는 커스텀 어노테이션 기반의 AOP 적용법까지 심도 있게 알아보았습니다.

AOP는 무분별하게 남용하면 애플리케이션의 실행 흐름을 파악하기 힘들어지는 '유지보수의 적'이 될 수 있지만, 트랜잭션, 로깅, 권한 체크 등 명확한 '공통 인프라 로직'에 적절히 사용한다면 코드의 품질을 비약적으로 끌어올려 주는 최고의 무기입니다. 오늘 예제를 직접 타이핑해 보시면서 AOP의 매력을 꼭 느껴보시길 바랍니다.

서블릿 필터 vs 스프링 인터셉터

J-Mandu — Sun, 26 Mar 2023 17:08:50 +0900

서블릿 필터

Filter란?

// 흐름
HTTP 요청 → WAS → 필터 → 서블릿 → 컨트롤러

// 제한
HTTP 요청 → WAS → 필터(서블릿 호출 x)

// 체인
HTTP 요청 → WAS → 필터 → 필터2 → 필터3 → 서블릿 → 컨트롤러

서블릿이 지원하는 기능으로 서블릿이 호출하기 전에 필터 로직이 실행되며,
특정 URL 패턴을 사용하여 특정 URL 요청에 대하여 적용할 수 있습니다.
필터는 로직에 의해서 적절하지 않은 요청이라고 판단할 경우 서블릿 호출을 하지 않습니다.
그리고 필터는 체인으로 구성되는데, 중간에 필터를 자유롭게 추가할 수 있습니다.
참고로 서블릿은 spring의 DispatcherServlet 입니다.

Filter 사용

public interface Filter {

    public default void init(FilterConfig filterConfig) throws ServletException {}

    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException;

    public default void destroy() {}
}

필터 인터페이스를 구현하고 등록하면 서블릿 컨테이너가 필터를 싱글톤 객체로 생성하고, 관리합니다.

init : 필터 초기화 메서드, 서블릿 컨테이너가 생성될 때 호출합니다.
doFilter : 요청이 올 떄 마다 해당 메서드가 호출됩니다.
destory : 필터 종료 메서드, 서블릿 컨테이너가 종료될 때 호출합니다.

@Slf4j
public class LogFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        String requestURI = httpRequest.getRequestURI();

        log.info("REQUEST [{}]", requestURI);
        chain.doFilter(request, response);
    }
}

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Bean
    public FilterRegistrationBean logFilter() {
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
        filterRegistrationBean.setFilter(new LogFilter());
        filterRegistrationBean.setOrder(1);
        filterRegistrationBean.addUrlPatterns("/*");
        return filterRegistrationBean;
    }

 /*
     필터 추가등록 방법
    @Bean
    public FilterRegistrationBean loginCheckFilter() {
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
        filterRegistrationBean.setFilter(new LoginCheckFilter());
        filterRegistrationBean.setOrder(2);
        filterRegistrationBean.addUrlPatterns("/posts/*");
        return filterRegistrationBean;
    }   
 */
}

SpringBoot의 내장 톰캣을 사용하는 경우에만 쓸 수 있는 방법입니다.
그 이유는 FilterRegistrationBean은 스프링 부트에서 필터를 내장 톰캣의 서블릿 컨텍스트에 추가할 수 있도록 지원하는 빈입니다.
만약 다른 was를 사용하는 경우 해당 was의 서블릿 컨텍스트에 필터를 등록할 수 있는 방법을 찾으시면 됩니다.
ex) jeus를 was로 사용하는 경우 web.xml을 통해 필터를 등록합니다.

doFilter

chain.doFilter()를 호출하여 다음 필터를 호출합니다. (다음 호출할 필터가 없는 경우 서블릿이 호출됩니다.)
ServletRequest, ServletResponse가 파라미터인 이유는 HTTP 요청이 아닌 경우까지 고려해서 만든 인터페이스이기 때문입니다.
그래서 HTTP를 사용하면 HTTPServletRequest, HTTPServletResponse로 인스턴스가 생성됩니다.
참고로 HTTPServletRequest, HTTPServletResponse는 ServletRequest, ServletResponse 상속합니다.

FilterRegistrationBean

setFilter : 필터를 등록합니다.
setOrder : 필터 순번을 정합니다.
addUrlPatterns : 필터를 적용시킬 url 패턴을 등록합니다.

스프링 인터셉터

Interceptor란?

// 흐름
HTTP 요청 → WAS → 필터 → 서블릿 → 인터셉터 → 컨트롤러

// 제한
HTTP 요청 → WAS → 필터 → 서블릿 → 인터셉터(컨트롤러 x)

// 체인
HTTP 요청 → WAS → 필터 → 서블릿 → 인터셉터 → 인터셉터2 → 인터셉터3 → 컨트롤러

스프링 MVC가 컨트롤러가 호출되기 전에 인터셉터가 호출이 됩니다.
인터셉터도 URL 패턴을 사용하여 특정 URL 요청에 대하여 적용할 수 있습니다.
서블릿 URL패턴과 다르게 매우 정밀하게 설정할 수 있습니다.
인터셉터도 로직에 의해서 적절하지 않은 요청이라고 판단할 경우 컨트롤러을 호출하지 않습니다.
인터셉터도 체인으로 구성되어 중간에 인터셉터를 자유롭게 추가할 수 있습니다.

Interceptor 사용

public interface HandlerInterceptor {

    default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
            throws Exception {
        return true;
    }


    default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
            @Nullable ModelAndView modelAndView) throws Exception {
    }


    default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
            @Nullable Exception ex) throws Exception {
    }
}

호출 흐름

preHandle : 핸들러 어댑터 호출전에 호출됩니다.
postHandle : 핸들러 어댑터 호출 후에 호출됩니다.
afterCompletion : 뷰 렌더링 이후에 호출됩니다.

예외가 발생시

preHandle : 핸들러 어댑터 호출전에 호출됩니다.
postHandle : 컨트롤러에서 예외가 발생할 경우 호출되지 않습니다.
afterCompletion : 항상 호출 되고, 예외 발생시 파라미터로 예외를 받아서 확인 할 수 있습니다.

@Sl4fj
public class LogInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
        Object handler) throws Exception {
        String requestURI = request.getRequestURI();
        log.error("preHandle {} {}", requestURI, handler);
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
        ModelAndView modelAndView) throws Exception {
        String requestURI = request.getRequestURI();
        log.error("postHandle {} {}", requestURI, handler);
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response,
        Object handler, Exception ex) throws Exception {
        String requestURI = request.getRequestURI();
        log.error("afterCompletion {} {}", requestURI, handler);
    }
}

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        WebMvcConfigurer.super.addInterceptors(registry);
        registry.addInterceptor(new LogInterceptor())
            .order(1)
            .addPathPatterns("/**");
            .excludePathPatterns("/", "/auth/login", "/auth/sign-up", "/auth/logout"
                , "/posts", "/css/**", "/img/**", "/error", "/favicon.ico");
    }
}

preHandle

리턴 타입이 true일 경우 다음 인터셉터를 호출합니다.(인터셉터가 없을경우 컨트롤러가 호출 됩니다.)
리턴 타입이 false일 경우 인터셉터나 컨트롤러를 호출하지 않습니다.

postHandle

컨트롤러가 호출 후에 호출이 되기때문에 ModelAndView를 확인할 수 있습니다.

afterCompletion

예외가 발생하여도 호출되기 때문에 Exception을 확인할 수 있습니다.

handler

@Controller, @RequestMapping인 경우 HandlerMethod 인스턴스가 생성됩니다.
/resources/static와 같은 정적 리소스인 경우 ResourceHttpRequestHandler 인스턴스가 생성됩니다.

addInterceptors

order : 인터셉터의 호출 순서를 정합니다.
addPathPatterns : 인터셉터를 적용할 URL 패턴을 지정합니다.
excludePathPatterns : 인터셉터에서 제외할 패턴을 지정합니다.

Filter와 Interceptor의 차이점

관리하는 컨테이너

Filter : spring과 상관없이 servlet에서 제공하는 기능이기 때문에 Servlet 컨테이너(was)에서 관리합니다.

Intercptor : spring mvc에서 제공되는 기능으로 spring 컨테이너에서 관리합니다.

처리 순서

Filter : 등록된 순서대로 처리되며(지정한 순번이 있으면 순번대로 처리), 마지막 Filter에서 처리가 완료되면
실제 요청을 처리하는 Servlet이 호출됩니다.

Interceptor : 지정한 순번대로 처리되며, 마지막 Interceptor에서 처리가 완료되면 실제 요청을 처리하는
HandlerApdator(controller)가 호출됩니다.

요청과 응답

Filter : HTTP 요청과 응답의 처리 전/후로 조작합니다.

Interceptor : HandlerApdaptor(controller) 요청과 응답의 처리 전/후로 조작합니다.

등록 방법

Filter : was에 따라 등록 방법이 다릅니다.

Interceptor : was에 상관없이 spring mvc에서 제공되는 방법으로 동일합니다.

구현 방법

Filter : java.servlet 패키지의 Filter 인터페이스를 통해 구현합니다.

Interceptor : org.springframework.web.servlet 패키지의 HandlerInterceptor 인터페이스를 통해 구현합니다.

Reference

https://www.baeldung.com/spring-mvc-handlerinterceptor-vs-filter
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2/dashboard
https://mangkyu.tistory.com/173

Git 기초

J-Mandu — Mon, 6 Mar 2023 09:40:00 +0900

설정

config

$ git config --global user.name "{사용자 이름}"
$ git config --global user.email {이메일}

Git을 설치하고 나서 가장 먼저 해야 하는 것은 사용자이름과 이메일 주소를 설정해야 합니다.
Git은 커밋할 때마다 이 정보를 사용하고 한 번 커밋한 후에는 정보를 변경할 수 없습니다.

$ git config --list
credential.helper=osxkeychain
core.excludesfile=/Users/{유저}/.gitignore_global
core.editor=vim
user.name={사용자 이름}
user.email={이메일}
init.defaultbranch=main
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
commit.template=/Users/minkyujin/.stCommitMsg
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true

$ git config user.name
jin

설정한 정보를 확인하고 싶을 때 --list 옵션을 줍니다.
git config 명령으로 특정 key에 대한 값을 확인할 수도 있습니다.

저장소 만들기

init

$ cd {디렉토리}

$ git init
{디렉토리} 안의 빈 깃 저장소를 다시 초기화했습니다

기존 디렉토리를 Git 저장소로 만들때 쓰는 명령어이고 해당 디렉토리에 .git 하위 디렉토리를 만듭니다.
.git 디렉토리에는 저장소에 필요한 뼈대 파일이 들어있습니다.

clone

// 디렉토리 명을 생략시 가져올 저장소 프로젝트 명으로 디렉토리가 생성됩니다.
$ git clone {저장소 주소}

$ git clone {저장소 주소} {디렉토리 명}

git 저장소를 복사하고 싶을 때 쓰는 명령어이고 프로젝트의 모든 데이터를 가져옵니다.

저장소에 저장하기

status

$ git status 
현재 브랜치 main

아직 커밋이 없습니다

추적하지 않는 파일:
  (커밋할 사항에 포함하려면 "git add <파일>..."을 사용하십시오)
    f1.txt

커밋할 사항을 추가하지 않았지만 추적하지 않는 파일이 있습니다 (추적하려면 "git add"를 사용하십시오)

파일의 상태를 확인하고 싶을 때 쓰는 명령어 입니다.
Untracked, Modified, Staged 상태들의 파일들을 보여줍니다.

status 내부 동작 원리

커밋할 사항이 없는 경우(clean) : Warking Directory, Staging Area(index), Local Repository(최신 Commit 개체의 Tree 개체)
내용이 모두 같을 경우
추적하지 않는 상태(Untracked) : StagingArea(index)에 Warking Directory의 파일들이 없는 경우
커밋하도록 정하지 않은 변경사항(Modified) : Stagin gArea(index)과 Warking Directory의 파일 내용들이 다른 경우
커밋할 변경 사항이 있는 경우(Staged) : Warking Directory, Staging Area(index)의 파일내용은 같지만
Local Repository(최신 Commit 개체의 Tree 개체)의 파일 내용이 다를 경우

add

$ git add {파일명}
현재 브랜치 main

아직 커밋이 없습니다

커밋할 변경 사항:
  (스테이지 해제하려면 "git rm --cached <파일>..."을 사용하십시오)
    새 파일:       f1.txt

파일을 새로 추적하고 싶을 때 쓰는 명령이고 commit에 추가될 Staged 상태입니다.
이미 Tracked 상태이지만 수정했을 경우 Staged 상태로 만들때도 사용합니다.
상태를 확인하는 명령어(status)를 사용하여 추적 상태를 볼수 있습니다.
Staged 상태 : Staging Area에 넣은 상태

add 내부 예상 동작 순서

// object 파일들
$ find .git/objects -type f
.git/objects/b6/8025345d5301abad4d9ec9166f455243a0d746
.git/objects/78/981922613b2afb6025042ff6bd878ac1994e85

// object 내용
$ git cat-file -p 78981922613b2afb6025042ff6bd878ac1994e85
a

// 인덱스
$ git ls-files -s
100644 78981922613b2afb6025042ff6bd878ac1994e85 0    f1.txt
100644 b68025345d5301abad4d9ec9166f455243a0d746 0    f2.txt
100644 78981922613b2afb6025042ff6bd878ac1994e85 0    f3.txt

파일 내용과 몇가지 부가적인 정보를 압축하여 그 결과를 해쉬 알고리즘(sha1) 통하여 해쉬 값을 얻습니다.
.git/objects/{해쉬 값 앞자리 2개}/{나머지 해쉬 값} 디렉토리와 파일을 만들고 파일내용을 저장합니다.
.git/index 파일에 object 파일명과 실제 파일명(add 한 파일명) 적어둡니다.

위와 같이 f1.txt와 f3.txt는 파일 내용이 같아서 인덱스에서 같은 obejct를 가르킵니다.

commit

// 쉘의 EDITOR 환경 변수에 등록된 편집기로 편집기가 실행되며 아래와 같은 메세지가 포함됩니다.
// git config --global core.editor 명령으로 어떤 편집기를 사용할지 설정할 수 있습니다.
$ git commit
# 변경 사항에 대한 커밋 메시지를 입력하십시오. '#' 문자로 시작하는
# 줄은 무시되고, 메시지를 입력하지 않으면 커밋이 중지됩니다.
#
# 현재 브랜치 main
# 커밋할 변경 사항:
#       수정함:        f1.txt
#

$ git commit -m {커밋 메세지}
[main (최상위-커밋) 0db3db0] 1
 1 file changed, 1 insertion(+)
 create mode 100644 f1.txt

$ git commit -am {커밋 메세지}

$ git commit --amend

Staging Area에 있는 변경사항에 대하여 버전을 만들고 local 저장소에 저장하고 싶을 때 쓰는 명령입니다.
커밋 메세지는 Angular 커밋 메세지 규약을 보고 작성합니다.
-a 옵션을 추가하여 Tracked 상태인 파일들을 자동으로 Staging Area에 넣어줍니다.
-m 옵션을 추가하여 인라인으로 메세지를 첨부할 수 있습니다.
--amend 옵션을 추가하여 이전 커밋을 덮어쓸 수 있습니다.

commit 내부 예상 동작 순서

// 현재 최신 커밋의 tree 개체 내용보기
$ git cat-file -p main^{tree}
100644 blob 78981922613b2afb6025042ff6bd878ac1994e85    f1.txt
100644 blob 2795c87096b42d4b7b8fda82a67dabded5c72c97    f2.txt
100644 blob 78981922613b2afb6025042ff6bd878ac1994e85    f3.txt
100644 blob 8baef1b4abc478178b004d62031cf7fe6db6f903    f4.txt

// 커밋 개체 내용보기
$ git cat-file -p 95d8893506c3c7c50d48b645e7a1f0bec74f1cb1
tree 1f1862a4f1875b673a186e10d99ac4b7044dc852
parent 527f5c509de3b26f3dee8eb432db618cbfa32cfb
author road-jin <rjswmtk@gmail.com> 1677822895 +0900
committer road-jin <rjswmtk@gmail.com> 1677822895 +0900

3

// 위의 커밋메시지에 있는 tree 개체 내용 보기
$ git cat-file -p 1f1862a4f1875b673a186e10d99ac4b7044dc852
100644 blob 78981922613b2afb6025042ff6bd878ac1994e85    f1.txt
100644 blob 2795c87096b42d4b7b8fda82a67dabded5c72c97    f2.txt
100644 blob 78981922613b2afb6025042ff6bd878ac1994e85    f3.txt
100644 blob 8baef1b4abc478178b004d62031cf7fe6db6f903    f4.txt

.git/objects/ 디렉토리에 Staging Area(index)의 상태대로 Tree object를 만듭니다.
.git/objects/ 디렉토리에 1번의 Tree 개체와 이전 Commit 개체와 Author/Committer 정보, 커밋 메시지를 토대로 Commit 개체를 만듭니다.

Tree 개체 : SHA-1 포인터, 파일 모드, 개체 타입, 파일 이름 순으로 작성되어 있고 Tree 개체를 통해서 커밋 시점의 파일들을 알 수 있습니다.
그리고 해당 시점을 찍어서 나타낸다는 의미로 스냅샷이라고 하고 스냅샷을 가지고 있는 구조를 Tree 개체라고 합니다.

Commit 개체 : Tree 개체, parent(이전 Commit 개체이며 없으면 생략), Author/Committer 정보, 줄바꿈,
commit message 순으로 작성되어 있습니다.

Author/Committer 정보 : Git 설정에서 했던 user.name과 user.email 정보를 가져옵니다.

Object 파일 종류

blob : 파일의 내용을 가지고 있습니다.
Tree 개체
Commit 개체

되돌리기

reset

// 원본 파일 생성
$ vi f1.txt
init

$ git add f1.txt

$ git commit 1

// 로컬 저장소에 저장할 파일
$ vi f1.txt
repository

$ git commit -am 2

// Staging Area(index)에 저장할 파일
$ vi f1.txt
index

$ git add f1.txt

// working directory에 저장할 파일
$ vi f1.txt
working directory

// 로컬 저장소의 f1.txt 내용 보기
$ git cat-file -p HEAD                                           
tree 7b60d3bfdfa15b16c74154cd889a52fd089c5117
author road-jin <rjswmtk@gmail.com> 1677997501 +0900
committer road-jin <rjswmtk@gmail.com> 1677997501 +0900

1

$ git cat-file -p 7b60d3bfdfa15b16c74154cd889a52fd089c5117
100644 blob 09d06c8f2087539716887077f2c0f8df5ab0ee24    f1.txt

$ git cat-file -p 09d06c8f2087539716887077f2c0f8df5ab0ee24
repository

// Staging Area(index)의 f1.txt 내용 보기
$ git ls-files -s
100644 9015a7a32ca0681be64471d3ac2f8c1f24c1040d 0    f1.txt

$ git cat-file -p 9015a7a32ca0681be64471d3ac2f8c1f24c1040d 
index

// working directory의 f1.txt 파일 내용 보기
$ cat f1.txt
working directory

$ git log
commit 1290e14f1e6d56a93f3e3e0e7c403ad15b5c4ca2 (HEAD -> main)
Author: road-jin <rjswmtk@gmail.com>
Date:   Sun Mar 5 15:38:06 2023 +0900

    2

commit 6df57e7dd878e6e0c08b93cda9ca733b4e882591
Author: road-jin <rjswmtk@gmail.com>
Date:   Sun Mar 5 15:37:50 2023 +0900

        1

// HEAD가 참조하고 있는 브랜치 파일내용을 해당 커밋개체로 수정합니다.
$ git reset --soft 6df57e7dd878e6e0c08b93cda9ca733b4e882591

$ cat .git/refs/heads/main
6df57e7dd878e6e0c08b93cda9ca733b4e882591

$ git diff
diff --git a/f1.txt b/f1.txt
index 9015a7a..31e5f9a 100644
--- a/f1.txt
+++ b/f1.txt
@@ -1 +1 @@
-index
+working directory

// repository에 reset 하기 전의 커밋개체로 수정(원상 복구)
$ git reset --soft ORIG_HEAD

// soft 옵션 + index 파일내용을 해당 커밋개체의 tree 개체를 기반으로 수정합니다.
$ git reset --mixed 6df57e7dd878e6e0c08b93cda9ca733b4e882591

$ git diff
diff --git a/f1.txt b/f1.txt
index b1b7161..31e5f9a 100644
--- a/f1.txt
+++ b/f1.txt
@@ -1 +1 @@
-init
+working directory

// working directory, index, repository 전부 f1.txt 파일내용이 repository로 변경
git reset --hard ORIG_HEAD

이전으로 돌아가고 싶을 때 쓰는 명령 입니다.
reset을 할 경우 .git/ORIG_HEAD 파일이 생성되고 내용에 reset 하기전의 커밋개체가 작성 되어있습니다.

Mode 옵션

기본값은 --mixed 입니다.

--soft {커밋 개체 해쉬 값} : HEAD가 참조하고 있는 브랜치 파일내용을 해당 커밋개체 해쉬 값으로 수정합니다.
ex) working directory와 staging area에는 남기고 다시 작업하고 싶을경우(커밋 취소)
-- mixed {커밋 개체 해쉬 값} : soft 옵션 + index 파일내용을 해당 커밋개체의 tree 개체를 기반으로 수정합니다.
ex) working directory 남기고 다시 작업하고 싶을 경우(Add 취소)
-- hard {커밋 개체 해쉬 값} : soft 옵션 + mixed 옵션 + 실제 파일 내용을 해당 커밋개체의 내용으로 수정합니다.
ex) 커밋 후 작업했던 내용들을 전부 날리고 다시하고 싶을 경우

revert

$ vi f1.txt
init

$ git add f1.txt

$ git commit -m 1

$ vi f1.txt
init
test

$ git commit -am 2

$ git log
commit 80d55e3a5c929264244ae89dfa5877f4c0289705
Author: road-jin <rjswmtk@gmail.com>
Date:   Sun Mar 5 20:56:49 2023 +0900

    2

commit 47d63f089cf93d4218630191609372326cf06a6b
Author: road-jin <rjswmtk@gmail.com>
Date:   Sun Mar 5 20:56:34 2023 +0900

    1

$ git revert 80d55e3a5c929264244ae89dfa5877f4c0289705
[main ebc07f9] Revert "2"
 1 file changed, 1 deletion(-)

$ cat f1.txt
init

$ git log
commit ebc07f90ef14f3c3a4218424e641e1b36d9b7bf3 (HEAD -> main)
Author: road-jin <rjswmtk@gmail.com>
Date:   Sun Mar 5 21:09:19 2023 +0900

    Revert "2"

    This reverts commit 80d55e3a5c929264244ae89dfa5877f4c0289705.

commit 80d55e3a5c929264244ae89dfa5877f4c0289705
Author: road-jin <rjswmtk@gmail.com>
Date:   Sun Mar 5 20:56:49 2023 +0900

    2

commit 47d63f089cf93d4218630191609372326cf06a6b
Author: road-jin <rjswmtk@gmail.com>
Date:   Sun Mar 5 20:56:34 2023 +0900

    1

해당 커밋 개체의 변화만 되돌리고 싶을 때 쓰는 명령어 입니다.
해당 커밋 개체의 변화만 되돌리고 커밋개체를 새로 생성합니다.
만약 47d63f089 커밋 개체로 revert를 할 경우
47d63f089 커밋 이후에 생긴 커밋 개체들의 변화들은 git이 처리하지 못하기 때문에 충돌현상 납니다.
그래서 사용자가 직접 충돌현상을 작업해야 하기 때문에 만약에 47d63f089 revert를 하고 싶으면
최상위 커밋 개체부터 차근차근 revert를 해야합니다.

브랜치 만들기

branch

// 브랜치 보기
$ git brach
* main

// 브랜치 생성
// 커밋 개체 해쉬 값이 없는 경우 최신 커밋 개체로 됨
$ git branch {브랜치 명} [{커밋 개체 해쉬 값}]

// 브랜치 보기
$ git branch
  exp
* main

// 브랜치 삭제
$ git branch -d {브랜치 명}

코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발하는 것이 브랜치입니다.
현재 브랜치를 모두 보여주는 명령어 입니다.
{브랜치 명} 옵션을 추가하면 브랜치를 생성해 줍니다.
-d {브랜치 명} 옵션을 추가하면 브랜치를 삭제합니다.

branch 내부 동작 원리

// 처음 깃 저장소를 만들시에 생성되는 HEAD
$ cat .git/HEAD
ref: refs/heads/main

// 파일 생성 후 내용 저장
$ vi f1.txt

// Staging Area 추가
$ git add f1.txt

// commit
$ git commit -m 1
[main (최상위-커밋) 07062c5] 1
 1 file changed, 1 insertion(+)
 create mode 100644 f1.txt

// main 브랜치가 어떤 커밋 개체를 가르키는지 확인
$ cat .git/refs/heads/main
07062c5e54b022fecdf6043226d73696f899527e

HEAD 파일은 git 저장소를 만들시에 생성되며 현재 브랜치를 나타내는 파일입니다.
브랜치들은 .git/refs/heads/{브랜치 명} 파일을 갖게 되고 커밋개체를 가르킵니다.
main 브랜치는 커밋을 하고난 후에 파일이 생기며 그 후에 생성되는 브랜치들은
main 커밋개체를 가르키기 때문에 바로 파일이 생성 됩니다.
해당 브랜치를 이동할 때 HEAD 파일 내용에 이동할 Branch 파일 디렉토리로 수정됩니다.
브랜치에서 커밋할 경우 Branch 파일 내용에 해당 커밋 개체 해쉬 값로 수정됩니다.

switch

// 브랜치 변경
$ git switch exp
'exp' 브랜치로 전환합니다

// 브랜치 생성 후 해당 브랜치로 변경
// 커밋 개체 해쉬 값이 없는 경우 최신 커밋 개체로 됨
$ git switch -c {브랜치 명} [{커밋 개체 해쉬 값}]

브랜치를 변경할 때 쓰는 명령어 입니다.
-c {브랜치 명} 옵션을 추가하여 브랜치를 생성할 수 있고 {커밋 개체 해쉬 값} 옵션을 주어
브랜치가 원하는 시점의 파일들을 가질 수 있게 해줍니다.

브랜치 정보확인

log

// 현재 브랜치의 커밋 목록
$ git log
commit b1a15fcf0dde684c19d8402c24316de2601e8b6f (HEAD -> main)
Author: road-jin <rjswmtk@gmail.com>
Date:   Sat Mar 4 00:05:06 2023 +0900

    4

commit 5a6fc468c7e6187d983e3a43a63dc337ea0aea67
Author: road-jin <rjswmtk@gmail.com>
Date:   Fri Mar 3 19:54:02 2023 +0900

    2

commit 013c5f61c7d303eb3e8ee1f28035747c460099d0
Author: road-jin <rjswmtk@gmail.com>
Date:   Fri Mar 3 19:53:43 2023 +0900

    1

// 모든 브랜치의 커밋 목록
$ git log --branches
commit b1a15fcf0dde684c19d8402c24316de2601e8b6f (HEAD -> main)
Author: road-jin <rjswmtk@gmail.com>
Date:   Sat Mar 4 00:05:06 2023 +0900

    4

commit 9f01c304fd6e1b7a9dafd296383ad1eeea54dd22 (exp)
Author: road-jin <rjswmtk@gmail.com>
Date:   Fri Mar 3 23:26:15 2023 +0900

    3

commit 5a6fc468c7e6187d983e3a43a63dc337ea0aea67
Author: road-jin <rjswmtk@gmail.com>
Date:   Fri Mar 3 19:54:02 2023 +0900

    2

commit 013c5f61c7d303eb3e8ee1f28035747c460099d0
Author: road-jin <rjswmtk@gmail.com>
Date:   Fri Mar 3 19:53:43 2023 +0900

    1

// 모든 브랜치의 커밋 목록을 간략하게 그래프 표시    
$ git log --branches --graph --oneline
* b1a15fc (HEAD -> main) 4
| * 9f01c30 (exp) 3
|/
* 5a6fc46 2
* 013c5f6 1

// 브랜치1에 없고 브랜치2에만 있는 커밋 내용 표시
$git log -p {브랜치1}..{브랜치2}
commit 9f01c304fd6e1b7a9dafd296383ad1eeea54dd22 (exp)
Author: road-jin <rjswmtk@gmail.com>
Date:   Fri Mar 3 23:26:15 2023 +0900

    3

diff --git a/f1.txt b/f1.txt
index 422c2b7..de98044 100644
--- a/f1.txt
+++ b/f1.txt
@@ -1,2 +1,3 @@
 a
 b
+c

브랜치에 대한 커밋 목록을 보고 싶을 때 쓰는 명령어 입니다.
--branches 옵션을 추가하면 모든 브랜치에 대한 커밋 목록을 보여줍니다.
-- graph -- oneline 옵션을 추가하면 모든 브랜치에 대한 커밋 목록을 그래프로 간략하게 표시해줍니다.
-p {브랜치1}..{브랜치2} 옵션을 추가하면 브랜치1에는 없고 브랜치2에는 있는 커밋한 파일들의 내용들을 비교해서 보여줍니다.

diff

$ git diff {브랜치1}..{브랜치2}
diff --git a/f1.txt b/f1.txt
index 422c2b7..de98044 100644
--- a/f1.txt
+++ b/f1.txt
@@ -1,2 +1,3 @@
 a
 b
+c
diff --git a/f2.txt b/f2.txt
deleted file mode 100644
index b0f6d94..0000000
--- a/f2.txt
+++ /dev/null
@@ -1 +0,0 @@
-4444

각각 브랜치에 대한 현재의 커밋 내용을 비교할 때 쓰는 명령어 입니다.

브랜치 합치기

merge

$ git merge {브랜치}
Merge made by the 'ort' strategy.
 f1.txt | 1 +
 1 file changed, 1 insertion(+)

// Fast-forward 전략을 사용하지 않고 merge
$ git merge {브랜치} --no-ff

현재 브랜치에서 {브랜치}의 내용들을 병합할 때 쓰는 명령어 입니다.
merge 전략에 따라 새로운 커밋 개체가 생성되고 커밋 메시지는 자동적으로 쓰여집니다.

merge 전략

Fast forward : 현재 브랜치 Head를 merge할 브랜치 Head로 변경하는 전략입니다.
어떤 브랜치를 사용했고 언제 병합했는지 기록이 남지않습니다.

3-way merge : Fast forward로 merge를 못할 경우 두 브랜치의 공통 조상이 되는 커밋과 두 브랜치의 커밋들을 비교하여
병합에 반영하고 충돌이 있는 내용은 사용자에게 해결을 맡기고 결과로 새로운 커밋을 생성합니다.

충돌 해결

$ git merge {브랜치}
자동 병합: common.txt
충돌 (내용): common.txt에 병합 충돌
자동 병합이 실패했습니다. 충돌을 바로잡고 결과물을 커밋하십시오.

$ git status
현재 브랜치 main
병합하지 않은 경로가 있습니다.
  (충돌을 바로잡고 "git commit"을 실행하십시오)
  (병합을 중단하려면 "git merge --abort"를 사용하십시오)

병합하지 않은 경로:
  (해결했다고 표시하려면 "git add <파일>..."을 사용하십시오)
    양쪽에서 수정:  common.txt

커밋할 변경 사항을 추가하지 않았습니다 ("git add" 및/또는 "git commit -a"를
사용하십시오)

$ vi common.txt
function b(){
}
<<<<<<< HEAD
function a(master, exp){
=======
function exp(){
>>>>>>> exp
}
function c(){
}

$ git add common.txt

$ git commit

충돌된 파일에서 <<<<<<< HEAD 아래 코드가 현재 브랜치 코드입니다.
======= 구분되어 있으며 구분 문자 바로 아래는 merge할 브랜치(exp)의 코드입니다.
충돌된 파일을 사용자가 직접 수정한 다음 커밋하면 정상적으로 merge가 됩니다.

rebase

$ git rebase {브랜치}
Successfully rebased and updated refs/heads/rb.

C3 에서 변경된 사항을 Patch로 만들고 이를 다시 C4 에 적용시키는 방법이 있다. Git에서는 이런 방식을 Rebase 라고 합니다.
커밋 히스토리를 나란히 만들면서 병합할 때 쓰는 명령어 입니다.
Rebase 할 브랜치에서 명령어 실행하고 {브랜치}는 합칠 브랜치입니다.

공개 저장소에 Push 한 커밋을 Rebase 하지말아야 합니다

충돌 해결

$ git rebase {브랜치}
자동 병합: f1.txt
충돌 (내용): f1.txt에 병합 충돌
error: 다음을 적용할(apply) 수 없습니다: 82aebb4... R1
힌트: Resolve all conflicts manually, mark them as resolved with
힌트: "git add/rm <conflicted_files>", then run "git rebase --continue".
힌트: You can instead skip this commit: run "git rebase --skip".
힌트: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 82aebb4... R1

$ git status
대화형 리베이스 진행 중. 갈 위치는 bf1987c
Last command done (1 command done):
   pick 82aebb4 R1
Next commands to do (2 remaining commands):
   pick eabced7 R2
   pick 0469d04 R3
  (보고 편집하려면 "git rebase --edit-todo"를 사용하십시오)
현재 'rb' 브랜치를 'bf1987c' 위로 리베이스하는 중입니다.
  (충돌을 바로잡고 "git rebase --continue"를 사용하십시오)
  (이 패치를 건너뛰려면 "git rebase --skip"을 사용하십시오)
  (원본 브랜치를 가져오려면 "git rebase --abort"를 사용하십시오)

병합하지 않은 경로:
  (use "git restore --staged <file>..." to unstage)
  (해결했다고 표시하려면 "git add <파일>..."을 사용하십시오)
A
    양쪽에서 수정:  f1.txt

커밋할 변경 사항을 추가하지 않았습니다 ("git add" 및/또는 "git commit -a"를
사용하십시오)
R2

$ vi f1.txt
충돌 수정

$ git add f1.txt

$ git rebase --continue
[HEAD 분리됨 e2e7796] R3
 1 file changed, 1 insertion(+), 1 deletion(-)
Successfully rebased and updated refs/heads/rb.

충돌된 파일에서 <<<<<<< HEAD 아래 코드가 현재 브랜치 코드입니다.
======= 구분되어 있으며 구분 문자 바로 아래는 rebase할 브랜치의 코드입니다.
충돌된 파일을 사용자가 직접 수정한 다음 rebase --continue 명령어를 실행합니다.

브랜치 작업 도중 다른 브랜치 이동

stash

// 임시 저장
$ git stash [push]
Saved working directory and index state WIP on exp: 3f440f9 1

// 최근 stash 적용
$ git stash apply
현재 브랜치 exp
커밋하도록 정하지 않은 변경 사항:
  (무엇을 커밋할지 바꾸려면 "git add <파일>..."을 사용하십시오)
  (use "git restore <file>..." to discard changes in working directory)
    수정함:        f1.txt

커밋할 변경 사항을 추가하지 않았습니다 ("git add" 및/또는 "git commit -a"를
사용하십시오)

// stash 조회
$ git stash list
stash@{0}: WIP on exp: 3f440f9 1

// 최근 stash 삭제
$ git stash drop
Dropped refs/stash@{0} (046135fef28ff0b48373d9421c570c3598a62768)

// apply와 drop을 합친 명령어
$ git stash pop

현재 브랜치에서 작업을 하던 도중에 커밋하지 않고 다른 브랜치로 이동할 경우 작업한 데이터들이 이동한 브랜치까지 영향을 줍니다.
현재 브랜치에서 작업을 임시로 저장할 때 쓰는 명령어 입니다.
push 옵션을 추가하면 Modified이면서 Tracked 상태인 파일과 Staging Area에 있는 파일들을 보관하고
Working Directory의 변경사항을 감춥니다.
apply 옵션을 추가하면 최근 stash에 저장해 두었던 작업들을 다시 불러옵니다.
list 옵션을 추가하면 stash들을 보여줍니다.
drop 옵션을 추가하면 최근 stash를 삭제 합니다.
pop 옵션을 추가하면 최근 stash에 저장해 두었던 작업들을 불러오고 해당 stash를 삭제합니다.

원격 저장소 만들기

remote

$ git remote add [-t {브랜치}] {원격 저장소 이름} {원격저장소 주소}

$ git remote -v

$ git remote remove {원격 저장소 이름}

기존 로컬 저장소와 원격 저장소를 연결할 때 쓴느 명령어 입니다.
add -t {브랜치 명}] {원격저장소 이름} {원격저장소 주소} 옵션을 추가하면 원격저장소와 연결이 됩니다.
-v 옵션을 추가하면 현재 연결된 원격 저장소들을 보여줍니다.
remove {원격저장소 이름} 옵션을 추가하면 원격 저장소를 연결 해제합니다.

내부 동작 원리

$ cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
        precomposeunicode = true
[remote "origin"]
        url = {원격 저장소 주소}
        fetch = +refs/heads/*:refs/remotes/origin/*
[remote "upstream"]
        url = {원격 저장소 주소}
        fetch = +refs/heads/만두:refs/remotes/upstream/만두

remote add시 .git/config 파일에 remote 정보가 추가됩니다.

clone

$ git clone {원격 저장소 주소} [디렉토리 명]

명령어를 실행한 디렉토리에 원격 저장소의 작업들을 복사하여 로컬저장소로 만듭니다.
기본적으로 remote 원격 저장소와 연결이 되어있으며 원격 저장소 이름은 origin으로 되어있습니다.

원격 저장소 동기화

push

$ git push {원격 저장소 이름} {브랜치}

// push 기본 원격 저장소 브랜치 설정
$ git push -u {원격 저장소 이름} {브랜치}

// 기본 원격 저장소 설정값으로 push하여 생략 가능합니다.
$ git push

로컬 저장소에 있는 작업들을 원격 저장소로 보낼때 쓰는 명령어 입니다.
{원격저장소 이름} {브랜치} 옵션을 추가하여 해당 원격 저장소의 브랜치에 작업들을 보냅니다.
-u {원격저장소 이름} {브랜치} 옵션을 추가하여 push 할 떄 기본 원격 저장소의 브랜치를 설정하여
다음 push할 때 부터 원격 저장소와 브랜치를 생략가능합니다.
설정 할때도 push 동작이 됩니다.

내부 동작 원리

$ git push --set-updatream orgin 만두

$ cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
        precomposeunicode = true
[remote "origin"]
        url = {원격 저장소 주소}
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "만두"]
        url = origin
        fetch = refs/heads/만두 
[remote "upstream"]
        url = {원격 저장소 주소}
        fetch = +refs/heads/만두:refs/remotes/upstream/만두

$ cat .git/refs/remotes/origin/만두
36db20f74f1130c97f412693e65cadcc2a48051a

$ cat .git/refs/heads/만두
36db20f74f1130c97f412693e65cadcc2a48051a

push를 할 경우 .git/refs/remotes/{원격 저장소 이름}/{브랜치} 파일 내용에 push 할 커밋개체가 쓰여집니다.
push --set-updatream {원격 저장소 이름} {브랜치} 옵션을 추가하면 .git/config에 해당 브랜치가 어떤 원격 저장소의 브랜치랑 연결되는지 추가됩니다.

fetch

$ git fetch [{원격 저장소 이름} {브랜치}]

원격 저장소에 있는 변경된 작업들을 가져오는것 까지만 해주는 명령어 입니다.
병합을 하기 전까지는 실제 로컬 저장소에는 영향을 미지치 않습니다.
변경된 작업을 가져온 경우 {원격 저장소 이름 } /{브랜치}로 새로운 브랜치가 만들어 집니다.
최신 커밋 개체들과 관련된 개체들을 다운받고 .git/refs/remotes/{원격 저장소 이름}/{브랜치} 파일 내용에 최신 커밋 개체 해쉬 값이 쓰여집니다.

pull

$ git pull [{원격 저장소 이름} {브랜치}]

원격 저장소에 있는 작업들을 가져오고 병합까지 해주는 명령어 입니다.
fetch + merge 명령어의 기능을 합친 명령어 입니다.
fetch 작업이 되고서 .git/refs/head/{브랜치} 파일 내용에 fast-forward인 경우
.git/refs/remotes/{원격 저장소 이름}/{브랜치} 파일의 커밋 개체 해쉬 값이 쓰여지게 됩니다.
3-way merge인 경우 충돌현상을 잡고서 새로운 커밋 개체가 생성이 되며 새로운 커밋 개체 해쉬 값이 쓰여지게 됩니다.

// Lightweight Tag
$ git tag {태그 이름} [{브랜치} | {커밋 개체 해쉬 값}]

// 태그 목록
$ git tag
1.0.0

// Annotated Tag
$ git tag -a {태그 이름} -m "{태그 메시지}" [{브랜치} | {커밋 개체 해쉬 값}]

$ git tag
1.0.0
1.1.0

// Annotated Tag 조회
$ git tag -v 1.1.0
object 5e4f4d28a075669c22e202b2ace4ec721f0ee19a
type commit
tag 1.1.0
tagger road-jin <rjswmtk@gmail.com> 1678020977 +0900

bug fix
error: no signature found

// Lightweight Tag 조회
$ git tag -v 1.0.0
error: 1.0.0: cannot verify a non-tag object of type commit.


$ git log
commit 5e4f4d28a075669c22e202b2ace4ec721f0ee19a (HEAD -> main, tag: 1.1.0)
Author: road-jin <rjswmtk@gmail.com>
Date:   Sun Mar 5 21:54:14 2023 +0900

    3

commit 392b8dd27c35a8e51a7cff1cfb81bbc98f179bea (tag: 1.0.0)
Author: road-jin <rjswmtk@gmail.com>
Date:   Sun Mar 5 21:52:46 2023 +0900

    2

commit e11f17504379addef52a0168160c4935a692d20e
Author: road-jin <rjswmtk@gmail.com>
Date:   Sun Mar 5 21:52:22 2023 +0900

    1

// 태그 삭제    
$ git tag -d {태그 이름}    

// 태그들 원격 저장소에 push
$ git push --tags

커밋 개체에 대한 태그를 붙일 때 쓰는 명령어 입니다.
Lightweight Tag는 커밋 개체에 대한 기본적인 태그정보만 저장합니다.
Annotated Tag는 태그 만든 사람, 언제 태그를 만들었는지, 태그 메시지를 저장합니다.
옵션을 추가하지 않으면 태그 목록들을 보여줍니다.
{태그 이름} [{브랜치} | {커밋 개체 해쉬 값}] 옵션을 추가하면 Lightweight Tag가 추가됩니다.
-a {태그 이름} -m "{태그 메시지}" [{브랜치} | {커밋 개체 해쉬 값}] 옵션을 추가하면 Annotated Tag가 추가됩니다.
-v {태그 이름} 옵션을 추가하면 해당 태그에 대한 정보를 보여줍니다.
-d {태그이름} 옵션을 추가하면 해당 태그를 삭제합니다.
push --tags 명령어를 사용해야만 원격 저장소에 태그들이 전송됩니다.

내부 동작 원리

$ cat .git/refs/tags/1.0.0
392b8dd27c35a8e51a7cff1cfb81bbc98f179bea

$ git cat-file -p 392b8dd27c35a8e51a7cff1cfb81bbc98f179bea
tree 36f609fa71850be13f5f97e4346cdf2488e7057c
parent e11f17504379addef52a0168160c4935a692d20e
author road-jin <rjswmtk@gmail.com> 1678020766 +0900
committer road-jin <rjswmtk@gmail.com> 1678020766 +0900

2

$ cat .git/refs/tags/1.1.0
ecf7866ccf4366341a90adc23febac09af4a6ff9

$ git cat-file -p ecf7866ccf4366341a90adc23febac09af4a6ff9
object 5e4f4d28a075669c22e202b2ace4ec721f0ee19a
type commit
tag 1.1.0
tagger road-jin <rjswmtk@gmail.com> 1678020977 +0900

bug fix

$ git cat-file -p 5e4f4d28a075669c22e202b2ace4ec721f0ee19a
tree 77aa31a93565e0c5809ff487b849af48ac7df624
parent 392b8dd27c35a8e51a7cff1cfb81bbc98f179bea
author road-jin <rjswmtk@gmail.com> 1678020854 +0900
committer road-jin <rjswmtk@gmail.com> 1678020854 +0900

3

Lightweight Tag인 경우 .git/refs/tags/{태그 이름}파일이 생성되며 내용에 커밋 개체 해쉬 값이 쓰여집니다.
Annotated Tag인 경우 objects 파일을 생성하고 내용에 태그 정보들과 커밋 개체 해쉬 값이 쓰여집니다.
그리고 .git/refs/tags/{태그 이름}파일이 생성되며 내용에 해당 objects 파일의 해쉬 값이 쓰여집니다.

참고

https://www.youtube.com/playlist?list=PLuHgQVnccGMA8iwZwrGyNXCGy2LAAsTXk

https://git-scm.com/book/ko/v2

https://www.inflearn.com/course/%EC%A0%9C%EB%8C%80%EB%A1%9C-%ED%8C%8C%EB%8A%94-%EA%B9%83

Java8 Optional API

J-Mandu — Fri, 6 May 2022 09:00:03 +0900

Optional이란?

Optional<T> Class는 Integer나 Double Class처럼 'T'타입의 객체를 포장해 주는 Wrapper Class이자 컨테이너 객체입니다.

컨테이너 안에 값이 들어 있을 수도 있고, 값이 없어 비어있는 컨테이너 일수도 있습니다.

해당 Optional은 Java 11 기준으로 설명하겠습니다.

Optional 특징

값이 비어있을 수도 있다는 가정하에 사용하므로 직관성이 좋습니다.
Null 값을 직접 사용하지 않아 NullPointerException 예외에 대하여 유연해집니다.
Null 체크 기능을 직접 구현 안 해도 됩니다.

Optional 생성

1. static <T> Optional<T> of(T value)

명시된 값을 가지는 Optional 객체를 반환합니다.

명시된 값이 아닌 null이 저장되는 경우에는 NullpointerException 예외가 발생합니다.

Optional<String> optional = Optional.of("String");
// null 값이 들어가면 NullPointerException 예외가 발생합니다.
Optional<Object> optional2 = Optional.of(null);

2. static <T> Optional<T> ofNullable(T value)

명시된 값이 null이 아니면 명시된 값을 가지는 Optional 객체를 반환하며,

명시된 값이 null일 경우 비어있는 Optional 객체를 반환합니다.

Optional<String> optional2 = Optional.ofNullable("4000");
Assertions.assertThat(optional2).isPresent();

Optional<String> optional = Optional.ofNullable(null);
Assertions.assertThat(optional).isEmpty();

3. static <T> Optional<T> empty()

아무런 값도 가지지 않는 비어있는 Optional 객체를 반환합니다.

Optional<Object> optional = Optional.empty();
Assertions.assertThat(optional).isEmpty();

Optional 메소드

1. boolean isPresent()

저장된 값이 존재하면 true를 반환하고, 값이 존재하지 않으면 false를 반환합니다.

Optional<String> optional = Optional.ofNullable("1234");
Assertions.assertThat(optional.isPresent()).isTrue();

Optional<String> optional2 = Optional.ofNullable(null);
Assertions.assertThat(optional2.isPresent()).isFalse();

2. boolean isEmpty()

저장된 값이 존재하지 않으면 true를 반환하고, 값이 존재하면 false를 반환합니다.

Optional<String> optional = Optional.ofNullable(null);
Assertions.assertThat(optional.isEmpty()).isTrue();

Optional<String> optional2 = Optional.ofNullable("1234");
Assertions.assertThat(optional2.isEmpty()).isFalse();

3. T get()

Optional 객체에 저장된 값을 반환합니다.

Optional<String> optional = Optional.ofNullable("Foo");
Assertions.assertThat(optional.get()).isEqualTo("Foo");

4. void ifPresent(Consumer<? super T> consumer)

값이 존재하면 해당 값으로 Consumer interface에 의한 지정된 작업을 수행합니다.

Optional<String> optional = Optional.ofNullable("Foo");
optional.ifPresent(System.out::println);

5. void ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction)

값이 존재하면 해당 값으로 Consumer interface에 의한 지정된 작업을 하고,

값이 존재하지 않으면 Runnable interface에 의한 지정된 작업을 합니다.

Optional<String> optional = Optional.ofNullable("Foo");
optional.ifPresentOrElse((string) -> Assertions.assertThat(string).isEqualTo("Foo")
                            , () -> Assertions.fail("NullPointerException", new NullPointerException()));

Assertions.assertThatThrownBy(() -> Optional.ofNullable(null)
                                            .ifPresentOrElse((string) -> Assertions.assertThat(string).isEqualTo("Foo")
                                                                , () -> Assertions.fail("NullPointerException"
                                                                                            , new NullPointerException())))
        .isInstanceOf(AssertionError.class);

6. Optional<T> or(Supplier<? extends Optional<? extends T>> supplier)

값이 존재하면 해당 값에 대한 Optional 객체가 반환되며,

값이 존재하지 않으면 Supplier interface에 의한 지정된 Optional<T> 객체가 반환됩니다.

String order = "banana";
Optional<String> optional = Optional.ofNullable(order)
                                    .or(() -> Optional.of("apple"));
Assertions.assertThat(optional.get()).isEqualTo("banana");

String order2 = null;
Optional<String> optional2 = Optional.ofNullable(order2)
                                     .or(() -> Optional.of("apple"));
Assertions.assertThat(optional2.get()).isEqualTo("apple");

7. T orElse(T other)

저장된 값이 존재하면 해당 값을 반환하고, 값이 존재하지 않으면 매개변수로 전달된 값을 반환합니다.

orElse(T other)에 T other는 Optional에 값이 있든 없든 무조건 실행되기 때문에

새로운 객체를 생성하거나, 새로운 연산을 수행하는 경우에는 orElseGet()을 써야합니다.

String order = "apple";
String eat = Optional.ofNullable(order).orElse("bread");
Assertions.assertThat(eat).isEqualTo("apple");

String order2 = null;
String eat2 = Optional.ofNullable(order2).orElse("bread");
Assertions.assertThat(eat2).isEqualTo("bread");

8. T orElseGet(Supplier<? extends T> supplier)

저장된 값이 존재하면 해당 값을 반환하고, 값이 존재하지 않으면 매개변수로 전달된 Supplier interface에 의한 객체를 반환합니다.

String order = "tomato";
String eat = Optional.ofNullable(order).orElseGet(() -> "banana");
Assertions.assertThat(eat).isEqualTo("tomato");

String order2 = null;
String eat2 = Optional.ofNullable(order2)
                     .orElseGet(() -> {
                                           System.out.println("banana");
                                           return "banana";
                                        });
Assertions.assertThat(eat2).isEqualTo("banana");

9. T orElseThrow()

저장된 값이 존재하면 그 값을 반환하고, 값이 존재하지 않으면 NoSuchElementException 예외를 발생시킵니다.

Assertions.assertThat(Optional.ofNullable("짜잔").orElseThrow())
        .isEqualTo("짜잔");

Assertions.assertThatThrownBy(() -> Optional.ofNullable(null).orElseThrow())
        .isInstanceOf(NoSuchElementException.class);

10. <X extends Throwable> T orElseThrow(Supplier<? extends X> exceptionSupplier)

저장된 값이 존재하면 그 값을 반환하고, 값이 존재하지 않으면 매개변수로 전달된 예외를 발생시킵니다.

Assertions.assertThat(Optional.ofNullable("짜잔").orElseThrow())
        .isEqualTo("짜잔");

Assertions.assertThatThrownBy(() -> Optional.ofNullable(null)
                                            .orElseThrow(() -> new NullPointerException()))
        .isInstanceOf(NullPointerException.class);

11. Optional<T> filter(Predicate<? super T> predicate)

저장된 값을 Predicate interface에 의한 구현된 조건이 True일 경우만 Optional<T>로 반환합니다.

class Order {
    private String coffee;

    public String getCoffee() {
        return coffee;
    }

    public void setCoffee(String coffee) {
        this.coffee = coffee;
    }
}

Order order = new Order();
order.setCoffee("딸기라떼");

Optional<Order> optional = Optional.ofNullable(order)
                                .filter((coffee) -> coffee.getCoffee().equals("딸기라떼"));
Assertions.assertThat(optional.isPresent()).isTrue();

Optional<Order> optional2 = Optional.ofNullable(order)
                                .filter((coffee) -> coffee.getCoffee().equals("초코라떼"));
Assertions.assertThat(optional2.isPresent()).isFalse();

12. <U> Optional<U> map(Function<? super T,? extends U> mapper)

저장된 값을 매개변수로 Function interface에 의한 지정된 값을 Optional에 감싸서 Optional<T>을 반환합니다.

class Order {
    private String coffee;

    public String getCoffee() {
        return coffee;
    }

    public void setCoffee(String coffee) {
        this.coffee = coffee;
    }
}

Order order = new Order();

Optional<String> optional = Optional.ofNullable(order).map(Order::getCoffee);
Assertions.assertThat(optional.isPresent()).isFalse();

order.setCoffee("딸기라떼");

Optional<String> optional2 = Optional.ofNullable(order).map(Order::getCoffee);
Assertions.assertThat(optional2.isPresent()).isTrue();

13. <U> Optional<U> flatMap(Function<? super T,? extends Optional<? extends U>> mapper)

저장된 값을 매개변수로 Function interface에 의한 지정된 Optional<T>을 반환합니다.

class Order {
    private String coffee;

    public Optional<String> getCoffee() {
        return Optional.ofNullable(coffee);
    }

    public void setCoffee(String coffee) {
        this.coffee = coffee;
    }
}

Order order = new Order();

Optional<String> optional = Optional.ofNullable(order).flatMap(Order::getCoffee);
Assertions.assertThat(optional.isPresent()).isFalse();

order.setCoffee("초코라떼");

Optional<String> optional2 = Optional.ofNullable(order).flatMap(Order::getCoffee);
Assertions.assertThat(optional2.isPresent()).isTrue();

주의사항

return 타입으로만 쓰기를 권장합니다.
- 메소드 매개변수 타입, 맵의 키 타입, 인스턴스 필드 타입으로 사용하지 않습니다.
Optional을 return 하는 메소드에서는 null을 리턴하지 않습니다.
기본형 타입의 Optional은 따로 있습니다.
- OptionalInt, OptionalLong 등..
Collection, Map, Stream Array, Optional은 Optional로 감싸지 않습니다.

이로써 공부한 내용을 간략히 정리해보았습니다.

감사합니다.

출처

https://www.inflearn.com/course/the-java-java8/dashboard

http://www.tcpschool.com/

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Optional.html

Java8 Stream API

J-Mandu — Wed, 4 May 2022 09:00:17 +0900

Stream이란?

다량의 데이터를 읽어온 다음, 사용자가 원하는 데이터로 가공하여 보여주는 객체입니다.

원본 데이터는 수정하지 않으며, Terminal Operation이 끝날 경우 소실됩니다.

Stream 구조

0 또는 다수의 Intermediate Operation(중개 연산)과 1개의 Terminal Operation(최종 연산)으로 구성되어 있습니다.

Intermediate Operation은 새로운 Stream을 반환하고 항상 Lazy(게을러)하여

Terminal Operation이 실행될 때까지 시작되지 않습니다.

출처 :http://www.tcpschool.com/java/java_stream_concept

Stream의 특징

원본 데이터를 수정하지 않습니다.
손쉽게 병렬 처리를 할 수 있습니다.
함수형 인터페이스를 지원합니다.
Stream은 일회성입니다.
Stream 작업은 내부 반복문으로 인하여 코드가 간결합니다.

Stream 생성

1. Collection 인터페이스를 구현한 모든 객체에 Stream() 메소드

List<String> list = new ArrayList<>();
Stream<String> stream = list.stream();

2. 배열에 관한 Stream을 생성하기 위한 Arrays클래스의 stream() 메소드

String[] arr = new String[]{"가","나","다","라"};
Stream<String> stream = Arrays.stream(arr);		// 가, 나, 다, 라
Stream<String> stream2 = Arrays.stream(arr, 0, 2);	// 가, 나

3. 매개변수를 받아 Stream을 생성하기 위한 Stream클래스의 of() 메소드

Stream<Integer> stream = Stream.of(4, 2, 3, 1);

4. 지정된 범위의 연속된 정수로 Stream을 생성하기 위한 IntStream클래스의 range() 및 rangeClosed() 메소드

IntStream stream1 = IntStream.range(1, 4);		// 1, 2, 3
IntStream stream2 = IntStream.rangeClosed(1, 4);	// 1, 2, 3, 4

5. 난수로 이루어진 Stream을 생성하기 위한 Random클래스의 ints(), longs(), doubles() 메소드

IntStream stream = new Random().ints(4);		// Int형의 랜덤한 숫자 4개
LongStream longs = new Random().longs(4);		// Long형의 랜덤한 숫자 4개
DoubleStream doubles = new Random().doubles(4);		// Double형의 랜덤한 숫자 4개

6. 람다 표현식에 의한 반환되는 값을 요소로 무한 Stream을 생성하기 위한 Stream클래스의 iterate() 및 generate() 메소드

Stream<Integer> stream = Stream.iterate(1, n -> n + 1);	// 1, 2, 3, 4 ...
Stream<Integer> stream2 = Stream.generate(() -> 1);	// 1, 1, 1, 1 ...

7. 파일의 한 행을 요소로 하는 Stream을 생성하기 위한 lines() 메소드

String<String> stream = Files.lines(Path path);

8. 아무 요소도 가지지 않는 빈 Stream을 생성하기 위한 Stream클래스의 empty() 메소드

Stream<Object> stream = Stream.empty();

Stream의 Intermediate Operation(중개 연산)

1. Stream 필터 : filter(), distinct()

Stream<T> filter(Predicate<? super T> predicate)

해당 Stream에서 주어진 조건에 맞는 데이터만으로 구성된 새로운 Stream을 반환합니다.

Stream<T> distinct()

해당 Stream에서 중복된 데이터를 제거 후 새로운 Stream을 반환합니다.

int[] arr = new int[]{1, 2, 3, 4, 5, 6, 7, 1, 2, 3};
IntStream filter = Arrays.stream(arr).filter(number -> number > 5);	// 6, 7
IntStream distinct = Arrays.stream(arr).distinct();			// 1, 2, 3, 4, 5, 6, 7

2. Stream 변경 : map(), flatMap()

<R> Stream<R> map(Functoin<? super T, ? extends R> mapper)

해당 Stream의 데이터들을 Function 매개변수로 전달하여, 그 반환 값으로 이루어진 새로운 Stream을 반환합니다.

<R> Stream<R> flatMap(Functoin<? super T, ? extends Stream<? extends R>> mapper)

해당 Stream의 데이터들을 Function 매개변수로 전달하여, Stream 반환 값으로 이루어진 새로운 Stream을 반환합니다.

String[] arr = {"A-01", "A-010", "B-02", "B-020"};
// 4, 5, 4, 5
Stream<Integer> stream = Arrays.stream(arr).map(string -> string.length());
// A, 01, A , 010, B, 02, B , 020
Stream<String> stream2 = Arrays.stream(arr).flatMap(string -> Stream.of(string.split("-")));

3. Stream 제한 : limit(), skip()

Stream<T> limit(long maxSize)

해당 Stream에서 매개변수로 전달된 개수만큼의 데이터만으로 이루어진 새로운 Stream을 반환합니다.

Stream<T> skip(long n)

해당 Stream에서 매개변수로 전달된 개수만큼을 제외한 나머지 데이터로 이루어진 새로운 Stream을 반환합니다.

Stream<Integer> stream = Stream.iterate(1, number -> number + 1);	// 1, 2, 3, 4, ...
Stream<Integer> stream2 = stream.skip(10);				// 11, 12, 13, 14, ...
Stream<Integer> stream3 = stream2.limit(3);				// 11, 12, 13

4. Stream 정렬 : sorted()

Stream<T> sorted()

해당 Stream의 데이터들을 오름차순으로 정렬합니다.

Stream<T> sorted(Comparator<? super T> comparator)

해당 Stream의 데이터들을 Comparator를 이용하여 정렬합니다.

Integer[] arr = {1, 5, 2, 35, 6, 9, 20, 12};
// 1, 2, 5, 6, 9, 12, 20, 35
Stream<Integer> sorted = Arrays.stream(arr).sorted();
// 1, 2, 5, 6, 9, 12, 20, 35
Stream<Integer> sorted1 = Arrays.stream(arr).sorted(Comparator.naturalOrder());

5. Stream 연산 결과 확인 : peek()

Stream<T> peek(Consumer<? super T> action)

해당 Stream으로부터 각 데이터들을 소모하여 명시된 동작을 수행하여 새로운 Stream을 반환합니다.

Integer[] arr = {1, 5, 2, 35, 6, 9, 20, 12};
Arrays.stream(arr).peek(number -> System.out.println("원본데이터 : " + number))
         .sorted()
         .peek(number -> System.out.println("sorted(): " + number))
         .limit(5)
         .peek(number -> System.out.println("limit(5) : " + number))
         .forEach(System.out::println);

Stream의 Terminal Operation(최종 연산)

1. Stream 출력 : forEach()

void forEach(Consumer<? super T> action)

해당 Stream의 각 데이터들을 소모하여 명시된 동작을 수행합니다.

Integer[] arr = {1, 5, 2, 35, 6, 9, 20, 12};
Arrays.stream(arr).sorted().forEach(System.out::println); // 1, 2, 5, 6, 9, 12, 20, 35

2. Stream 소모 : reduce()

Optional<T> reduce(BinaryOperator<T> accumulator)

처음 두 데이터를 가지고 연산을 수행한 뒤, 그 결과와 다음 요소를 가지고 또다시 연산을 수행합니다.

이런 식으로 해당 Stream의 모든 데이터들을 소모하여 연산을 수행하고, 그 결과를 반환합니다.

T reduce(T identity, BinaryOperator<T> accumulator)

위와 같으며, 첫 번째 매개변수가 초기값을 가지고 시작하므로 Optional이 아닌 T타입을 반환합니다.

Integer[] arr = {1, 5, 2, 35, 6, 9, 20, 12};
Optional<Integer> reduce = Arrays.stream(arr).reduce((n, n2) -> n + n2); // 90
Integer reduce2 = Arrays.stream(arr).reduce(10, (n, n2) -> n + n2);	// 100

3. Stream 검색 : findFirst(), findAny()

Optional<T> findFirst()

해당 Stream에서 첫 번째 데이터를 참조하는 Optional을 반환합니다.

Optional<T> findAny()

해당 Stream에서 병렬 Stream일 경우 가장 먼저 찾은 데이터를 참조하는 Optional을 반환합니다.

병렬 Stream이 아닐 경우는 findFirst()와 같습니다.

String[] arr = {"a", "a1", "b", "b1", "c", "c1", "b2", "c2"};
// b
Optional<String> findFirst = Arrays.stream(arr).filter(string -> string.startsWith("b")).findFirst();
// b
Optional<String> parallelFindFirst = Arrays.stream(arr).parallel().filter(string -> string.startsWith("b")).findFirst();
// b
Optional<String> findAny = Arrays.stream(arr).findAny();
// b, b1, b2 셋 중 하나
Optional<String> parallelFindAny = Arrays.stream(arr).parallel().filter(string -> string.startsWith("b")).findAny();

4. Stream 검사 : anyMatch(), allMatch(), noneMatch()

boolean anyMatch(Predicate<? super T> predicate)

해당 Stream의 일부 데이터가 특정 조건을 만족할 경우에 true를 반환합니다.

boolean allMatch(Predicate<? super T> predicate)

해당 Stream의 모든 데이터가 특정 조건을 만족할 경우에 true를 반환합니다.

boolean noneMatch(Predicate<? super T> predicate)

해당 Stream의 모든 데이터가 특정 조건을 만족하지 않을 경우에 true를 반환합니다.

String[] arr = {"a1", "b1", "c1"};
boolean anyMatch = Arrays.stream(arr).anyMatch(string -> string.startsWith("a"));   //true
boolean allMatch = Arrays.stream(arr).allMatch(string -> string.contains("1"));	    //true
boolean noneMatch = Arrays.stream(arr).noneMatch(string -> string.startsWith("d")); //true

5. Stream 통계 : count(), min(), max()

long count()

해당 Stream의 데이터의 개수를 반환합니다.

Optional<T> min(Comparator<? super T> comparator)

해당 Stream의 데이터 중에서 가장 큰 값을 가지고 있는 데이터를 참조하는 Optional을 반환합니다.

Optional<T> max(Comparator<? super T> comparator)

해당 Stream의 데이터 중에서 가장 작은 값을 가지고 있는 데이터를 참조하는 Optional을 반환합니다.

Integer[] arr = {100, 50, 200, 300, 420};
// 5
long count = Arrays.stream(arr).count();
// 420
Optional<Integer> max = Arrays.stream(arr).max(Integer::compareTo);
// 50
Optional<Integer> min = Arrays.stream(arr).min(Integer::compareTo);

6. Stream 연산 : sum(), average()

T sum()

해당 Stream의 모든 데이터 합을 구하여 반환합니다.

Optional<T> average()

해당 Stream의 모든 데이터 평균값을 구하여 반환합니다.

// sum() 및 average() 메소드는 IntStream or DoubleStream과 같은 기본 타입 스트림에서 사용할 수 있습니다.
// 1070
int sum = IntStream.of(100, 50, 200, 300, 420).sum();
// 214.0
OptionalDouble average = IntStream.of(100, 50, 200, 300, 420).average();

7. Stream 수집 : collect()

<R,A> R collect(Collector<? super T,A,R> collector)

매개변수로 전달된 Collectors 객체에 구현된 방법대로 Stream 데이터를 수집하여 반환합니다.

Integer[] arr = {100, 50, 200, 300, 420, 300};
// [100, 50, 200, 300, 420, 300]
List<Integer> collect = Arrays.stream(arr).collect(Collectors.toList());
// [50, 100, 420, 200, 300]
Set<Integer> collect2 = Arrays.stream(arr).collect(Collectors.toSet());
// {Key100=100, Key420=420, Key200=200, Key300=300, Key50=50}
Map<String, Integer> collect3 = Arrays.stream(arr).collect(toMap((integer) -> "Key" + integer, (integer) -> integer, (oldVal, newVal) -> oldVal));
// 10050200300420300
String collect4 = Arrays.stream(arr).map(integer -> String.valueOf(integer)).collect(Collectors.joining());
// {50=[50], 420=[420], 100=[100], 200=[200], 300=[300, 300]}
Map<Integer, List<Integer>> collect5 = Stream.of(arr).collect(Collectors.groupingBy(Integer::intValue, toList()));
// [100, 50, 200, 300, 420, 300]
ArrayList<Integer> collect6 = Stream.of(arr).collect(Collectors.toCollection(ArrayList::new));

이로써 공부한 내용을 간략히 정리해보았습니다.

감사합니다.

출처

https://www.inflearn.com/course/the-java-java8/dashboard

http://www.tcpschool.com/

자바 함수형 인터페이스(Functional Interface)와 람다 표현식(Lambda Expressions)

J-Mandu — Thu, 14 Apr 2022 09:00:47 +0900

함수형 인터페이스(Functional Interface)란?

추상 메소드를 단 하나만 가지고 있는 SAM (Single Abstract Method) 인터페이스입니다.

@FuncationInterface 애노테이션을 가지고 있습니다.

함수형 인터페이스를 더 알아보기 전에 우선 람다 표현식 및 메소드 레퍼런스부터 알아보겠습니다.

람다 표현식(Lambda Expressions)이란?

함수형 인터페이스의 인스턴스를 만드는 방법으로 쓰일 수 있습니다.

메소드 매개변수, 리턴 타입, 변수로 만들어 사용할 수도 있습니다.

그리고 코드를 확연히 줄일 수 있습니다.

RunSomething runSomething = new RunSomething() {
    @Override
    public int doIt(int number) {
        return number + 10;
    }
};

RunSomething rambda = number -> number + 10;

표현식 : ( 인자 리스트 ) -> { 바디 }

인자 리스트

인자가 없을 때 : ()
인자가 한 개 일 때 : (one) 또는 one
인자가 여러개 일 때 : (one, two)
인자의 타입은 생략 가능하고 명시할 수도 있습니다. : (Integer one, Integer two)

바디

화살표 오른쪽에 함수 본문을 정의합니다.
여러 줄인 경우에 {}를 사용해서 묶습니다.
한 줄인 경우에 생략 가능하며, return도 생략이 가능합니다.

변수 캡처 (Variable Capture)

로컬변수캡처
final이거나 effective final 인 경우에만 참조할 수 있습니다.
concurrency 문제가 생길 수 있어서 컴파일에러가 발생합니다.
```
public static void main(String[] args) {
        int baseNumber = 10;

        RunSomething rambda = number ->{
            return baseNumber;
        };
}
```
effective final
자바 8부터 지원하는 기능으로 “사실상" final인 변수입니다.
final 키워드 사용하지 않은 변수를 익명 클래스 구현체 또는 람다에서 참조할 수 있습니다.

익명 클래스 구현체와 달리 ‘쉐도 윙(Shadowing)’ 하지 않습니다.
익명 클래스는 새로 스코프를 만들지만, 람다는 람다를 감싸고 있는 스코프와 같습니다.
그래서 람다 스코프와 람다를 감싸고 있는 스코프(main Method)에 똑같은 변수명을 쓰지 못합니다.
- 쉐도 윙이란 ?
  외부 클래스의 변수명과 내부 클래스의 변수명 그리고 내부 클래스 내의 메서드 파라미터명이 같을 경우
  외부 클래스의 변수가 가려지면서, 내부클래스의 변수나 내부 클래스 내의 파라미터가 쓰여집니다.

메소드 레퍼런스란?

람다가 하는 일이 기존 메소드 또는 생성자를 호출하는 거라면, 메소드 레퍼런스를 사용하면 람다와 다르게 간결하게 표현할 수 있다.

public class Greeting {

    private String name;

    public Greeting() {

    }

    public Greeting(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public String hello(String name){
        return "hello " + name;
    }

    public static String hi (String name){
        return "hi " + name;
    }
}

// 스태틱 메소드 참조
UnaryOperator<String> hi = Greeting::hi;

// 특정 객체의 인스턴스 메소드 참조
Greeting greeting = new Greeting();
UnaryOperator<String> hello = greeting::hello;

// 임의 객체의 인스턴스 메소드 참조
String [] name = {"minkyu", "com", "example"};
Arrays.sort(name, String::compareToIgnoreCase);

//생성자 참조
Supplier<Greeting> newGreeting = Greeting::new;

메소드 참조하는 방법

스태틱 메소드 참조 > 타입::스태틱 메소드
특정 객체의 인스턴스 메소드 참조 > 객체 레퍼런스::인스턴스 메소드
임의 객체의 인스턴스 메소드 참조 > 타입::인스턴스 메소드
생성자 참조 > 타입::new

메소드 또는 생성자의 매개변수로 람다의 입력값을 받습니다.

리턴 값 또는 생성한 객체는 람다의 리턴 값입니다.

자바에서 기본적으로 제공하는 함수형 인터페이스가 있습니다.

java.util.function 패키지 중 자주 사용할만한 함수 인터페이스들을 자세히 살펴보겠습니다.

@Test
public void functionTest(){
    Function<Integer, Integer> plus10 = (number) -> number + 10;
    Function<Integer, Integer> multiply2 = (number) -> number * 2;
    Function<Integer, Integer> functionCompose = plus10.compose(multiply2);
    Function<Integer, Integer> functionAndThen = plus10.andThen(multiply2);

    Assertions.assertThat(plus10.apply(2)).isEqualTo(12);
    Assertions.assertThat(multiply2.apply(2)).isEqualTo(4);
    Assertions.assertThat(functionCompose.apply(2)).isEqualTo(14);
    Assertions.assertThat(functionAndThen.apply(2)).isEqualTo(24);
}

Function<T, R>

T타입을 받아서 R타입을 리턴하는 함수 인터페이스입니다.

R apply(T t)
함수 조합용 메소드
- andThen
- compose

@Test
public void biFunctionTest(){
    Function<Integer, Integer> plus10 = (number) -> number + 10;
    BiFunction<Integer, Integer, Integer> biFunctionSum = (number, number2) -> number + number2;
    BiFunction<Integer, Integer, Integer> biFunctionAndThen = biFunctionSum.andThen(plus10);

    Assertions.assertThat(biFunctionSum.apply(4,8)).isEqualTo(12);
    Assertions.assertThat(biFunctionAndThen.apply(4,8)).isEqualTo(22);
}

BiFunction<T, U, R>

두 개의 값(T, U)을 받아서 R 타입을 리턴하는 함수 인터페이스입니다.

R apply(T t, U u)
함수 조합용 메소드
- andThen

@Test
public void consumerTest(){
    ArrayList<Integer> list = new ArrayList<>();

    Consumer<Integer> addList = (age) -> list.add(age);
    Consumer<Integer> addListPlus10 = (name) -> list.add(name + 10 );
    Consumer<Integer> consumerAndThen = addList.andThen(addListPlus10);

    addList.accept(30);
    Assertions.assertThat(list.size()).isEqualTo(1);
    Assertions.assertThat(list.get(0)).isEqualTo(30);

    list.clear();
    consumerAndThen.accept(30);
    Assertions.assertThat(list.size()).isEqualTo(2);
    Assertions.assertThat(list.get(0)).isEqualTo(30);
    Assertions.assertThat(list.get(1)).isEqualTo(40);
}

Consumer<T>

T타입을 받아서 아무 값도 리턴하지 않는 함수 인터페이스입니다.

void accept(T t)
함수 조합용 메소드
- andThen

@Test
public void supplierTest(){
    Supplier<Integer> getAge = () -> 30;
    Assertions.assertThat(getAge.get()).isEqualTo(30);
}

Supplier<T>

T타입의 값을 제공하는 함수 인터페이스입니다.

T get()

@Test
public void predicateTest(){
    Predicate<Integer> isEven = (number) -> number % 2 == 0;
    Predicate<Integer> isTen = (number) -> number.equals(10);

    Assertions.assertThat(isEven.test(10)).isEqualTo(true);
    Assertions.assertThat(isEven.and(isTen).test(10)).isEqualTo(true);
    Assertions.assertThat(isEven.or(isTen).test(4)).isEqualTo(true);
    Assertions.assertThat(isEven.negate().test(2)).isEqualTo(false);
}

Predicate<T>

T타입을 받아서 boolean을 리턴하는 함수 인터페이스입니다.

boolean test(T t)
함수 조합용 메소드
- and
- or
- negate

@Test
public void unaryOperator(){
    UnaryOperator<Integer> plusTen = (number) -> number + 10;
    Assertions.assertThat(plusTen.apply(10)).isEqualTo(20);
}

UnaryOperator<T>

Function<T, R>의 특수한 형태로, 입력값 하나를 받아서 동일한 타입을 리턴하는 함수 인터페이스입니다.

R apply(T t)
함수 조합용 메소드
- andThen
- compose

@Test
public void BinaryOpreator(){
    BinaryOperator<Integer> binarySum = (number, number2) -> number + number2;
    Assertions.assertThat(binarySum.apply(5,8)).isEqualTo(13);
}

BinaryOperaor<T>

BiFunction<T, U, R>의 특수한 형태로, 동일한 타입의 입력값 두 개를 받아 리턴하는 함수 인터페이스입니다.

R apply(T t, U u)
함수 조합용 메소드
- andThen

끝으로 자바에서 함수형 프로그래밍 대해 살펴보겠습니다.

순수 함수(Pure function)란?

함수 밖에 있는 값을 변경하거나 사용하지 않고, 동일한 입력에 대하여 항상 동일한 출력을 반환하는 함수입니다.

Side Effect가 없다. (함수 밖에 있는 값을 변경하지 않습니다.)
상태가 없다. (함수 밖에 있는 값을 사용하지 않습니다.)

고차 함수(Higher-Order Function)란?

함수가 함수를 매개변수로 받을 수 있고 함수를 리턴할 수도 있습니다.

이로써 공부한 내용을 간략히 정리해보았습니다.

감사합니다.

출처

https://www.inflearn.com/course/the-java-java8/dashboard

자바 인터페이스(Interface)

J-Mandu — Wed, 13 Apr 2022 09:00:50 +0900

인터페이스란?

클래스들이 구현해야 하는 동작들을 추상적으로 선언하는 추상 자료형입니다.

Interface라는 키워드를 사용하여 선언합니다.

강제적으로 구현해야 하는 추상 메소드가 있으며, static과 final이 둘 다 선언되는 상수가 있습니다.

자바 8버전부터, default 메소드와 static 메소드를 인터페이스에 구현할 수 있습니다.

기존 자바 7버전 이하에서는 추상화 클래스에서 공통코드를 구현체 메소드로 구현하여 상속 할 경우

추상화 클래스만 상속 받을 수 있기 때문에 더 이상 상속이 불가능하였습니다.

하지만, 자바 8버전부터는 인터페이스에서 default 메소드와 static 메소드가 추가되어 상속에 대하여 자유가 생겼습니다.

기본 메소드(Default Method)

인터페이스에 메소드를 구현할 수 있습니다.

Object가 제공하는 기능(equals, hasCode 등)은 기본 메소드로 제공할 수 없습니다.

스태틱 메소드(Static Method)

해당 타입 관련 헬퍼 또는 유틸리티 메소드를 제공할 때 인터페이스에 스태틱 메소드를 제공할 수 있습니다.

public interface HandPhone {
    String getModelName();

    /**
     * @implSpec
     * 핸드폰 스펙(Model Name)을 리턴
     */
    default Map<String, String> getSpec(){
        Map<String, String> map = new HashMap<>();
        map.put("model", getModelName());
        return map;
    }

    /**
     * @implSpec
     * 핸드폰 스펙(Model Name)을 출력
     */
    default void printSpec() {
        System.out.println("Model Name : " + getUpperName(getModelName()));
    }

    static String getUpperName(String name){
        return name.toUpperCase();
    }
}

기본 메소드는 해당 인터페이스를 구현한 클래스가 있을 경우 기본 메소드를 추가하여도 구현체가 깨지지 않습니다.

하지만, 기본 메소드는 구현체 모르게 추가된 기능으로 반드시 문서화를 하는 게 좋습니다.(@implSpec 자바 독 태그)

public interface IPhone extends HandPhone {
    String SIZE = "71.5 × 146.7 × 7.65 mm";

    void printSpec();

    /**
     * @implSpec
     * HandPhone Interface 재정의 함수 
     * 핸드폰 스펙(Size, Model Name)을 리턴
     */
    @Override
    default Map<String, String> getSpec() {
        Map<String, String> map = new HashMap<>();
        map.put("size", SIZE);
        map.put("model", HandPhone.getUpperName(getModelName()));
        return map;
    }
}

기본 메소드는 인터페이스를 상속받는 인터페이스에서 다시 추상 메소드로 변경할 수 있습니다.

또한 인터페이스 구현체가 기본 메소드를 재정의 할 수도 있습니다.

public class IPhone13 implements IPhone{

    @Override
    public String getModelName() {
        return "IPhone13(A2633)";
    }

    @Override
    public void printSpec() {
        System.out.println("Size : " + SIZE);
        System.out.println("Model Name : " + HandPhone.getUpperName(getModelName()));
    }
}

추상 메소드 getModelName()과 printSpec을 구현하였습니다.

public class HandPhoneTest {

    HandPhone iPhone13 = new IPhone13();

    @Test
    public void 모델명가져오기(){
        Assertions.assertThat(iPhone13.getModelName()).isEqualTo("IPhone13(A2633)");
    }

    @Test
    public void 스펙가져오기및출력(){
        Map<String, String> iPhone13Spec = iPhone13.getSpec();

        Assertions.assertThat(iPhone13Spec.size()).isEqualTo(2);
        Assertions.assertThat(iPhone13Spec.get("size")).isEqualTo("71.5 × 146.7 × 7.65 mm");
        Assertions.assertThat(iPhone13Spec.get("model")).isEqualTo("IPHONE13(A2633)");

        iPhone13.printSpec();
    }
}

IPhone 인터페이스를 구현한 IPhone13 클래스를 테스트하기 위하여 테스트 케이스를 작성하였습니다.

getModelName() 메소드로 모델명을 가져오고,

getSpec() 메소드를 통하여 핸드폰 사이즈 및 모델명(대문자 변환)을 테스트해보았습니다.

이로써 공부한 내용을 간략히 정리해보았습니다.

감사합니다.

출처

https://www.inflearn.com/course/the-java-java8/dashboard

애노테이션 프로세서(Annotation processor)

J-Mandu — Wed, 6 Apr 2022 09:00:58 +0900

Annotation Processor란?

Annotation Processor는 컴파일 단계에서 Annotation에 정의된 일렬의 프로세스를 동작하게 하는 것을 의미합니다.

컴파일 단계에서 실행되기 때문에, 빌드 단계에서 에러를 출력하게 할 수 있고, 소스코드 및 바이트 코드를 생성할 수도 있습니다.

사용하는 예로 자바의 @Override가 있으며, Lombok(롬북)이라는 라이브러리도 있습니다.

Lombok은 자주 사용하는 라이브러리로 한번 살펴보겠습니다.

Lombok이란?

@Getter, @Seteer, @Builder 등의 Annotation과 Annotation Processor를 제공하여 표준적으로

작성해야 할 코드를 개발자 대신 생성해주는 라이브러리 입니다.

컴파일 시점에 Annnotation Processor를 사용하여 abstract syntaxtree를 조작합니다.

그러면, 프로젝트를 생성하여 Lombok 라이브러리를 실습해보겠습니다.

Preferences -> Plugins설정에서 IntelliJ Lombok 플러그인을 설치합니다.

Preferences -> Build,Execution,Deployment -> Compiler -> Annotation Processors설정에서

Enable Anntation processing 체크박스를 활성화합니다.

Lombok Annotation을 사용하는 클래스는 변경할 때마다 그대로 적용이 되어 Maven Complie을 안 해도 되는 설정입니다.

<dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
      <version>1.18.8</version>
      <scope>provided</scope>
</dependency>

pom.xml에 lombok 라이브러리 dependency를 추가합니다.

package me.whiteship;


import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.Setter;

@Getter @Setter @EqualsAndHashCode
public class Member {

    private String name;

    private int age;
}

@Getter : 전역 변수에 대한 Getter를 생성합니다.

@Setter : 전역 변수에 대한 Setter를 생성합니다.

@EqualsAndHashCode : Equals 함수와 HashCode 함수를 재정의하여 생성합니다.

package me.whiteship;

import org.junit.Assert;
import org.junit.Test;

import static org.junit.Assert.*;

public class MemberTest {

    @Test
    public void getterSetter(){
        Member member = new Member();
        member.setName("minkyu");

        Assert.assertEquals(member.getName(), "minkyu");
    }

}

소스코드에 getter 및 setter 함수를 개발자가 직접 만들지 않아도

setName 및 getName 함수를 쓸 수 있으며, 테스트 코드도 통과하는 것을 확인할 수 있습니다.

이제 Annotation Processor에 대해 살펴보겠습니다.

Processor Interface를 통하여 Annotation Processor를 구현하고,

Processor Interface는 여러 라운드(rounds)에 거쳐 Source 및 Compile 된 코드를 처리할 수 있습니다.

참조 : https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/annotation/processing/Processor.html

Abstract Pocessor라는 추상 클래스를 상속하여 Annotation Processor를 구현해 보겠습니다.

Annotation Processor Jar 프로젝트를 생성해 보겠습니다.

 <!-- https://mvnrepository.com/artifact/com.google.auto.service/auto-service -->
<dependency>
  <groupId>com.google.auto.service</groupId>
  <artifactId>auto-service</artifactId>
  <version>1.0.1</version>
</dependency>

<!-- https://mvnrepository.com/artifact/com.squareup/javapoet -->
<dependency>
  <groupId>com.squareup</groupId>
  <artifactId>javapoet</artifactId>
  <version>1.13.0</version>
</dependency>

AutoService 및 Javapoet 라이브러리를 추가해줍니다.

AutoService : Java SPI(서비스 프로바이더 인터페이스) 구성 파일을 생성하는데

도움이 되는 Annotation processor 라이브러리입니다.

컴파일 시점에 Annotaion Processor를 사용하여

META-INF/services/javax.annotation.processor.Processor 파일 등 필요한 파일을 자동으로 생성해줍니다.

참고 : https://www.baeldung.com/google-autoservice

Javapoet : Source Code(.java)파일을 생성해주는 라이브러리입니다.

package me.whiteship;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.SOURCE)
public @interface Magic {
}

Annotation 범위는 Interface, Enum, Class, Annotation이고,

Annotation 유지는 Annotation Processor의 컴파일 시점까지만 필요하기 때문에

Source Code까지만 유지합니다.

package me.whiteship;

import com.google.auto.service.AutoService;
import com.squareup.javapoet.ClassName;
import com.squareup.javapoet.JavaFile;
import com.squareup.javapoet.MethodSpec;
import com.squareup.javapoet.TypeSpec;

import javax.annotation.processing.AbstractProcessor;
import javax.annotation.processing.Filer;
import javax.annotation.processing.Processor;
import javax.annotation.processing.RoundEnvironment;
import javax.lang.model.SourceVersion;
import javax.lang.model.element.*;
import javax.tools.Diagnostic;
import java.io.IOException;
import java.util.Set;

@AutoService(Processor.class)
public class MagicMojaProcessor extends AbstractProcessor {

    // 이 프로세서가 어떤 애노테이션을 처리 할 것 인지 정하는 메소드
    @Override
    public Set<String> getSupportedAnnotationTypes() {
        return Set.of(Magic.class.getName());
    }
    
    // 어떤 소스버전을 지원 할지 정하는 메소드 
    @Override
    public SourceVersion getSupportedSourceVersion() {
        return SourceVersion.latestSupported();
    }
    
    // 해당 애노테이션으로 작업을 처리하는 메소드
    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {      
        // 해당 애노테이션이 붙어 있는 엘리먼트들을 가져 온다.
        // Element : 클래스, 인터페이스, 메소드 등 애노테이션을 붙일 수 있는 target
        Set<? extends Element> elements = roundEnv.getElementsAnnotatedWith(Magic.class);
        for (Element element: elements) {
            // 해당 Element 이름
            Name simpleName = element.getSimpleName();

            // 해당 Element가 Interface가 아닌 경우 빌드에서 에러나게 동작
            if (element.getKind() != ElementKind.INTERFACE) {
                processingEnv.getMessager().printMessage(Diagnostic.Kind.ERROR, "Magic annotation can not be used on " + simpleName);
            } else {
                processingEnv.getMessager().printMessage(Diagnostic.Kind.NOTE, "Processing " + simpleName);
            }

            TypeElement typeElement = (TypeElement) element;
            ClassName className = ClassName.get(typeElement);

            // MethodSpec: Method 만드는 객체
            MethodSpec pullout = MethodSpec.methodBuilder("pullOut")
                    .addModifiers(Modifier.PUBLIC)          // 접근 제한자 설정
                    .returns(String.class)                  // Method return Type 설정
                    .addStatement("return $S", "Rabiit!")   // return 시 값 전달 설정
                    .build();

            // TypeSpec : Type 만드는 객체
            TypeSpec magicMoja = TypeSpec.classBuilder("MagicMoja")
                    .addModifiers(Modifier.PUBLIC)  // 접근 제한자 설정
                    .addMethod(pullout)             // 해당 클래스에 메소드 추가
                    .addSuperinterface(className)
                    .build();

            // Filer : 소스코드,클래스코드 및 리소스를 생성할 수 있는 인터페이스
            // processingEnv : AbstractProcessor 상속 받으면 쓸 수 있는 전역 변수
            Filer filer = processingEnv.getFiler();
            try {
                JavaFile.builder(className.packageName(), magicMoja)
                        .build()
                        .writeTo(filer);
            } catch (IOException e) {
                processingEnv.getMessager().printMessage(Diagnostic.Kind.ERROR, "FATAL ERROR : " + e);
            }
        }

        /*
          true 일 경우 해당 애노테이션에 대한 다른 프로세서한테 더이상 처리하지 말라고 한다.
          false 일 경우 또 다른 프로세서가 처리 할 수 있음.
        */
        return true;
    }
}

Java Processing API를 살펴보겠습니다.

roundEnv.getElementsAnnotatedWith(Magic.class) : Magic Annotation이 붙어 있는 Element들을 가져옵니다.

Element : 클래스, 인터페이스, 메소드 등 애노테이션을 붙일 수 있는 target

getKind() : 해당 Type 종류를 반환합니다. ex) ElementKind.INTERFACE
getSimpleName() : 해당 Type의 이름을 반환합니다. ex) Interface 이름

Filer : Source Code, Class Code 및 리소스를 생성할 수 있는 인터페이스

AbstractProcessor의 구현한 메소드들을 살펴보겠습니다.

getSupportedAnnotationTypes() : 이 Processor가 어떤 Annotation을 처리할 것인지를 정의하는 메소드입니다.
getSupportedSourceVersion() : 어떤 자바버전을 지원할지 정의하는 메소드입니다.
process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv)
AbstractProcessor의 필수적으로 구현해야 하며, Processor가 어떻게 동작해야 하는지를 정의하는 메소드입니다.
return 값이 true일 경우 해당 Annotation에 대한 다른 Processor한테 더 이상 처리하지 말라고 합니다.
false일 경우 또 다른 Processor가 처리할 수 있습니다.

Javapoet 라이브러리를 이용한 객체들을 살펴보겠습니다.

MethodSpec : Method 정보를 가지고(생성하는) 있는 객체입니다.

MethodSpec.methodBuilder("pullOut") : 빌더 패턴 생성자로서, pullOut이라는 메소드명을 정의합니다.
addModifiers(Modifier.PUBLIC) : 접근 제한자를 Public으로 정의합니다.
returns(String.class) :Method return Type을 String으로 정의합니다.
addStatement("return $S", "Rabiit!") : Method가 진행할 코드를 정의합니다.
build() : 위의 정의한 내용으로 인스턴스를 생성합니다.

TypeSpec : Type 정보를 가지고(생성하는) 있는 객체

TypeSpec.classBuilder("MagicMoja") : 빌더 패턴 생성자로서, MagicMoja라는 클래스 명을 정의합니다.
addModifiers(Modifier.PUBLIC) : 접근 제한자를 Public으로 정의합니다.
addMethod(pullout) : 클래스에 메소드를 추가합니다.
addSuperinterface(className) : 상속할 Interface를 추가합니다.
build() : 위의 정의한 내용으로 인스턴스를 생성합니다.

JavaFile : Source Code(.java)파일로 생성해주는 객체

builder(className.packageName(), magicMoja) : 빌더 패턴 생성자로서,
Source Code파일의 패키지명과 생성할 Type을 정의합니다.
build() : 위의 정의한 내용으로 인스턴스를 생성합니다.
writeTo(filer) : 파일로 생성합니다.

프로젝트를 로컬 메이븐 저장소에 추가하여 사용하기 위해 maven clean install 명령어를 실행합니다.

이제 저희가 만든 Annotation Processor가 어떻게 동작하는지 확인하기 위해

테스트할 프로젝트를 생성해보겠습니다.

<dependency>
      <groupId>we.whiteship</groupId>
      <artifactId>magicmoja</artifactId>
      <version>1.0-SNAPSHOT</version>
</dependency>

프로젝트 생성 후 pom.xml에 Annotation Processor 프로젝트의 groupId, artifactId, version 복사하여 dependency에 추가합니다.

package org.example;

import we.whiteship.Magic;

@Magic
public interface Moja {
    String pullOut();
}

저희가 만든 Magic Annotation을 Moja Interface에 적용합니다.

Preferences -> Build,Execution,Deployment -> Compiler > Annotation Processors설정에서

Enable annotation processing 체크박스를 활성화합니다.

annotation processing은 컴파일 시점에 Annotation을 스캔하고 처리하기 위해 자바 컴파일러에 삽입된 툴입니다.

컴파일 시점에서 annotation processing이 만든 클래스를 참조하기 위해 설정합니다.

Maven Compile 명령어를 실행합니다.

프로젝트 우클릭 -> Open Module Settings -> Project Settings -> Modules설정에서

target -> generated-sources -> annotations폴더를 클릭하고 Sources폴더 그림을 클릭하여 활성화합니다.

Annotation Processor가 만든 클래스를 다른 클래스가 참조할 수 있게 소스 경로로 인식하게 해줘야 합니다.

package org.example;

public class App 
{
    public static void main( String[] args ) {
        Moja moja = new MagicMoja();
        System.out.println(moja.pullOut());
    }
}

실행하면 빌드 화면에서는 Processing Moja가 출력이 되고,

Run 화면에서는 Rabbit이 출력됩니다.

이로써 공부한 내용을 간략히 정리해보았습니다.

감사합니다.

출처

https://www.inflearn.com/course/the-java-code-manipulation

프록시 패턴(Proxy Pattern)

J-Mandu — Tue, 5 Apr 2022 09:00:01 +0900

출처 :https://www.inflearn.com/course/the-java-code-manipulation

프록시 패턴이란?

리얼 서브젝트는 자신이 해야 할 일만 하면서 프록시를 사용하여 부가적인 기능을 제공할 때 쓰는 패턴입니다.

프록시와 리얼 서브젝트가 공유하는 인터페이스(서브젝트)가 있고,

클라이언트가 해당 인터페이스(서브젝트) 타입으로 프록시를 사용합니다.

클라이언트는 프록시를 거쳐서 리얼 서브젝트를 사용하기 때문에 프록시는

리얼 서브젝트에 대한 접근을 관리하거나 부가기능을 제공하거나, 리턴값을 변경할 수도 있습니다.

그럼 프로젝트를 생성해서 간단히 살펴보겠습니다.

package me.whiteship;

public class Book {

    private Integer id;

    private String title;

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }
}

package me.whiteship;

public interface BookService {
    void rent(Book book);
}

서브젝트

package me.whiteship;

public class BookServiceProxy implements  BookService {

    BookService bookService;

    public BookServiceProxy(BookService bookService) {
        this.bookService = bookService;
    }

    @Override
    public void rent(Book book) {
        System.out.println("aaaaa");
        bookService.rent(book);
        System.out.println("bbbbb");
    }
}

프록시

package me.whiteship;

public class DefaultBookService implements BookService {

    @Override
    public void rent(Book book) {
        System.out.println("rent : " + book.getTitle());
    }
}

리얼 서브젝트

package me.whiteship;

import org.junit.Test;
import static org.junit.Assert.*;

public class BookServiceTest {
    BookService bookService = new DefaultBookService();
    BookService bookServiceProxy = new BookServiceProxy(new DefaultBookService());

    @Test
    public void noProxy() {
        Book book = new Book();
        book.setTitle("spring");
        bookService.rent(book);
    }

    @Test
    public void proxy() {
        Book book = new Book();
        book.setTitle("spring");
        bookServiceProxy.rent(book);
    }
}

noProxy 메소드는 spring이 출력되며,

proxy() 예상대로

aaaaa

rent : spring

bbbbb

이렇게 출력됩니다.

이런 식으로 프록시 패턴을 구현할 수도 있으며

다른 방법으로 자바에서 지원하는 Dynamic Proxy를 살펴보겠습니다.

Dynamic Proxy란?

Runtime에 특정 interface들을 구현하는 class 또는 instance를 만드는 기술입니다.

애플리케이션은 다이나믹 프록시를 사용하여 여러 임의의 이벤트 인터페이스를 구현하는 객체를 만들 수 있습니다.

Object Proxy.newProxyInstance(ClassLoader, Interfaces, InvocationHandler)

https://docs.oracle.com/javase/8/docs/technotes/guides/reflection/proxy.html

실습을 위해 프로젝트를 생성하고 살펴보겠습니다.

package me.whiteship;

public class Book {

    private Integer id;

    private String title;

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }
}

package me.whiteship;

public interface BookService {

    void rent(Book book);

    void returnBook(Book book);
}

package me.whiteship;

public class DefaultBookService implements BookService {

    @Override
    public void rent(Book book) {

        System.out.println("rent : " + book.getTitle());
    }

    @Override
    public void returnBook(Book book) {
        System.out.println("return : "+ book.getTitle());
    }
}

package me.whiteship;

import org.junit.Test;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import static org.junit.Assert.*;

public class BookServiceTest {
    BookService bookService = (BookService) Proxy.newProxyInstance(BookService.class.getClassLoader(), new Class[]{BookService.class}
            , new InvocationHandler() {
                BookService bookService = new DefaultBookService();
                @Override
                public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                    if(method.getName().equals("rent")) {
                        System.out.println("aaaa");
                        Object invoke = method.invoke(bookService, args);
                        System.out.println("bbbb");
                        return invoke;
                    }
                    return method.invoke(bookService, args);
                }
            });

    @Test
    public void dynamicProxy() {
        Book book = new Book();
        book.setTitle("spring");
        bookService.rent(book);
        bookService.returnBook(book);
    }
}

Proxy.newProxyInstance를 사용하여 이전의 실습한 BookServiceProxy 클래스를 구현한 코드입니다.

dynamicPorxy 메소드의 결과값은

aaaa

rent : spring

bbbb

return : spring 이렇게 출력됩니다.

BookService의 타입을 DefaultBookService로 바꾸면 에러가 납니다.

그 이유는 Interface 기반의 proxy는 생성할 수 있지만, class 기반의 proxy는 생성 할 수가 없기 때문입니다.

따라서, java proxy는 무조건 interface를 써야 한다는 제약 조건이 있습니다.

그러면 class기반의 proxy가 필요할 경우 어떻게 해야 할까요?

class기반의 proxy는 서브 클래스를 만들 수 있는 라이브러리를 사용하여 proxy를 만들 수 있습니다.

서브 클래스를 만드는 방법의 단점을 살펴보겠습니다.

상속을 사용하지 못하는 경우 프록시를 만들 수 없습니다.
- private 생성자만 있는 경우
- Final 클래스인 경우

라이브러리 ByteBuddy를 사용하여 실습해 보겠습니다.

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>me.whiteship</groupId>
  <artifactId>javaproxy</artifactId>
  <version>1.0-SNAPSHOT</version>

  <name>demospringdi</name>
  <!-- FIXME change it to the project's website -->
  <url>http://www.example.com</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
  </properties>

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>

    <!-- https://mvnrepository.com/artifact/net.bytebuddy/byte-buddy -->
    <dependency>
      <groupId>net.bytebuddy</groupId>
      <artifactId>byte-buddy</artifactId>
      <version>1.12.8</version>
    </dependency>
  </dependencies>
</project>

package me.whiteship;

import net.bytebuddy.ByteBuddy;
import net.bytebuddy.implementation.InvocationHandlerAdapter;
import org.junit.Test;


import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

import static net.bytebuddy.matcher.ElementMatchers.named;
import static org.junit.Assert.*;

public class BookServiceTest {

    @Test
    public void dynamicProxy() throws Exception{
        Class<? extends DefaultBookService> proxyClass = new ByteBuddy().subclass(DefaultBookService.class)
                .method(named("rent")).intercept(InvocationHandlerAdapter.of(new InvocationHandler() {
                    DefaultBookService defaultBookService = new DefaultBookService();

                    @Override
                    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                        System.out.println("aaaa");
                        Object invoke = method.invoke(defaultBookService, args);
                        System.out.println("bbbb");
                        return invoke;
                    }
                }))
                .make().load(DefaultBookService.class.getClassLoader()).getLoaded();

        DefaultBookService bookService = proxyClass.getConstructor(null).newInstance();

        Book book = new Book();
        book.setTitle("spring");
        bookService.rent(book);
        bookService.returnBook(book);
    }
}

자바 Dynamic Proxy 실습과 마찬가지로 똑같이 구현되게 테스트 코드를 작성하였습니다.

dynamicProxy 메소드의 결과값은

aaaa

rent : spring

bbbb

return : spring 이렇게 출력됩니다.

Dynamic Proxy는 런타임에 인터페이스 또는 클래스의 인스턴스 또는 클래스를 만들어 사용하는 프로그래밍 기법입니다.

사용처는 Spring data JPA, Spring AOP, Mockito 등이 있습니다.

이로써 공부한 내용을 간략히 정리해보았습니다.

감사합니다.

출처

https://www.inflearn.com/course/the-java-code-manipulation

자바 리플렉션(Reflection)2 - Annotation, Dependency Injection(DI)

J-Mandu — Mon, 4 Apr 2022 09:00:55 +0900

지난 리플렉션 시간에 이어서 리플렉션을 활용하여

Spring의 DI(Dependency Injection)을 약간 비슷하게 따라 해 보겠습니다.

일단 DI를 쓸 때, 주로 Annotation을 사용합니다.

그래서 이 애노테이션을 활용하여, DI를 구현하려고 합니다.

Annotation에 관하여 살펴보겠습니다.

프로젝트는 저번 시간(리플렉션)에 이어서 진행합니다.

package me.whiteship;

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

public @interface MyAnnotation {
}

Annotation을 생성합니다.

package me.whiteship;

@MyAnnotation()
class Book {
    public static String A = "A";

    private String B = "B";

    public Book() {

    }

    public Book(String b) {
        B = b;
    }

    private void c () {
        System.out.println("C");
    }

    public int sum (int left, int right){
        return left + right;
    }
}

저번 시간에 생성한 Book클래스에 Annotation을 적용합니다.

package me.whiteship;

import java.util.Arrays;

public class App 
{
    public static void main( String[] args ) {
	// getAnnotations(): 상속받은 (@Inherit) 애노테이션까지 조회
	// getDeclaredAnnotations(): 자기 자신에만 붙어있는 애노테이션 조회
        Arrays.stream(Book.class.getAnnotations()).forEach(System.out::println);
    }
}

리플렉션을 이용하여 Book 클래스에 있는 Annotation 조회하여 출력합니다.

출력 값은???

아무것도 출력되지 않습니다.

기본적으로 Annotation은 주석(코멘트)이랑 같은 취급을 받으며, 클래스 파일까지 Annotation 정보가 유지됩니다.

지금부터 Annotation에 대해 자세히 살펴보겠습니다.

package me.whiteship;

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

@Retention(RetentionPolicy.RUNTIME)
public @interface MyAnnotation {
}

@Retention(RetentionPolicy.속성명) : Annotation이 어느 시점까지 유지할지 정하는 Annotation입니다.

속성명
- SOURCE : Java Source File에서만 Annotation 정보가 유지됩니다.
- CLASS : Class File까지 Annotation 정보가 유지되고, 리플렉션을 이용하여 Annotation 정보를 얻을 수는 없습니다.
- RUNTIME : Class File 및 RunTime까지 Annotation 정보가 유지되고,
  리플렉션을 이용하여 Annotation 정보를 얻을 수 있습니다.

- Annotation 생성 시 @Retention이 없는 경우에는 기본값으로 @Rentention(RetentionPolicy.CLASS) 입니다.

package me.whiteship;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.FIELD})
public @interface MyAnnotation {
}

@Target(ElementType.속성) : 해당 Annotation을 적용할 대상을 정하는 Annotation입니다.

속성명
- TYPE : Class, Interface, Enum, Annotation
- ANNOTATION_TYPE : Annotation
- FIELD : FIELD(변수), Enum
- CONSTRUCTOR : Constructor(생성자)
- METHOD : Method
- LOCAL_VARIABLE : local variable(로컬 변수)
- PACKAGE : package
- PARAMETER : Parameter(매개변수)
- 그 외 여러가지 속성명이 있습니다.
  참고 : https://docs.oracle.com/javase/8/docs/api/java/lang/annotation/ElementType.html

package me.whiteship;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.FIELD})
@Inherited 
public @interface MyAnnotation {

    String value() default "minkyu";

    //int number() default 100;
 
    //Class book() default Book.class;
}

@Ingerited : 상속할 경우 서브 클래스에도 Annotation이 적용되게 할 경우 이 Annotation을 씁니다.

package me.whiteship;

@MyAnnotation("minkyu")
//@MyAnnotation(value = "minkyu", number = 200, book = MyBook.class)
public class Book {

....
..

Annotation에서 변수 선언할 때, default 값을 안 주고,

해당 Annotation을 사용한 대상에서 초기값을 선언을 안 하면 컴파일 에러가 발생합니다.

변수명이 value일 경우 @MyAnnotation("minkyu") 바로 초기값 선언이 가능합니다.

변수 타입은 기본형 타입, String, Enum, Annotation, Class만 허용됩니다.

이상 Annotation에 관하여 살펴보았습니다.

이제 Annotation을 적용하면, 리플렉션을 활용하여 인스턴스가 생성되는 간단한 프로젝트를 만들어 보겠습니다.

package me.whiteship.di;

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

@Retention(RetentionPolicy.RUNTIME)
public @interface Inject {

}

리플렉션을 활용하기 때문에 Annotation이 Runtime까지 유지되어야 합니다.

package me.whiteship.di;

import java.lang.reflect.InvocationTargetException;
import java.util.Arrays;

public class ContainerService {

    public static <T> T getObject(Class<T> classType ) {
        T instance = createInstance(classType);
        Arrays.stream(classType.getDeclaredFields()).forEach(field -> {
            if (field.getAnnotation(Inject.class) != null) {
                Object fieldInstance = createInstance(field.getType());
                field.setAccessible(true);
                try {
                    field.set(instance, fieldInstance);
                } catch (IllegalAccessException e) {
                    throw new RuntimeException(e);
                }

            }
        });
        return instance;
    }

    private static <T> T createInstance(Class<T> classType) {
        try {
            return classType.getConstructor(null).newInstance();
        } catch (InstantiationException | IllegalAccessException | InvocationTargetException | NoSuchMethodException e) {
            throw new RuntimeException(e);
        }
    }
}

createInstance Method

Class<T> 타입에 대한 인스턴스를 생성합니다.

getObject Method

매개변수 Class<T>에 대한 인스턴스를 생성(createInstance)하고,

해당 T 타입의 모든 변수에 Inject Annotation이 적용되어 있는지 확인하여

적용이 되어 있는 경우에 해당 변수에 변수 타입의 인스턴스를 생성하여 주입합니다.

모든 변수가 확인이 되었으면, 리턴 값으로 매개변수 타입에 대한 인스턴스를 반환합니다.

제너릭 메소드

<T> T getObect(Class<T> classType)

제네릭으로 매개변수 Class타입으로 return 한다는 내용입니다.

모든 클래스는 Class<T> Instance가 생깁니다.

자세한 내용은 https://devlog-wjdrbs96.tistory.com/201 참고 부탁드립니다.

package me.whiteship.di;

public class BookRepository {
}

package me.whiteship.di;

public class BookService {

    @Inject
    BookRepository bookRepository;
}

package me.whiteship.di;

import org.junit.Test;

import static org.junit.Assert.assertNotNull;

public class ContainerServiceTest {

    @Test
    public void getObject_BookRepository() {
        BookRepository bookRepository = ContainerService.getObject(BookRepository.class);
        assertNotNull(bookRepository);
    }

    @Test
    public void getObject_BookService() {
        BookService bookService = ContainerService.getObject(BookService.class);
        assertNotNull(bookService);
        assertNotNull(bookService.bookRepository);
    }
}

getObject_BookRepository 메소드는 ContainerService 클래스의 getOjbect를 활용하여

인스턴스를 생성하여 변수에 주입하고 해당 변수가 null값이 아닌지 확인하는 테스트 코드입니다.

getObject_BookService 메소드는 위와 비슷하지만,

BookService에 전역 변수 bookRepository에 Inject Annotation이 적용되어 있어

bookRepository도 인스턴스가 생성되어 주입되어 있는지 확인하는 테스트 코드입니다.

두 개의 메소드 테스트 결과는 당연히 성공입니다.

이렇게 리플렉션을 살펴보았습니다.

리플렉션의 기능들이 막강하지만, 주의할 점도 있습니다.

지나친 사용은 성능 이슈를 야기할 수 있습니다.
컴파일 시점에 확인되지 않고 런타임 시에만 발생하는 문제를 만들 가능성이 있습니다.
접근 지시자를 무시할 수 있습니다.

리플렉션 사용처는

스프링에서 의존성 주입, MVC View에서 넘어온 데이터를 객체에 바인딩 할때

하이버네이트 @Entity 클래스에 Setter가 없다면 리플렉션을 사용합니다.

이로써 공부한 내용을 간략히 정리해보았습니다.

감사합니다.

출처

https://www.inflearn.com/course/the-java-code-manipulation