AOP가 필요한 상황

사실 AOP는 이걸 언제 쓰는지 알면 정말 쉽다. 

디테일 한 부분은 천천히 배우자. <- 보통 이 디테일한 부분먼저 배우기 시작해서 굉장히 어려움 

 

AOP가 필요한 상황

- 모든 메소드의 호출 시간을 측정하고 싶다면?

- 공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern)

- 회원 가입 시간, 회원 조회 시간을 측정하고 싶다면? 

 

예시) 악덕 상사가 모든 메소드의 시간을 알고 싶다고 시간을 다 찍으라고 함. 근데 초단위로 찍워줬더니 밀리세컨드 단위로 다시 찍어오라는 상황을 가정하자. 

 

MemberService를 아래와 같은 코드로 다시 작성해주었다. 

public Long join(Member member){
        long start = System.currentTimeMillis();
        try{
            //같은 이름이 있는 중복 회원X
            validateDuplicateMember(member);
            memberRepository.save(member);
            return member.getId();
        } finally{
            long finsh = System.currentTimeMillis();
            long timeMs = finsh - start;
            System.out.println("join = " + timeMs + "ms");
        }

    }

이런식으로 currentTimeMillis를 받아서 초를 구해주었다. 이후에 Test를 돌려보자. 

182ms가 나와 있는 모습이다.

나머지 메소드 위에 millis를 구해보자. 

public List<Member> findMembers(){
        long start = System.currentTimeMillis();
        try{
            return memberRepository.findAll();
        } finally {
            long finsh = System.currentTimeMillis();
            long timeMs = finsh - start;
            System.out.println("findMembers "+ timeMs + "ms");
        }

    }

이렇게 findMembers의 ms도 구해준다. 

성능이 많고 용량이 거대한 것들은 웜업을 한번 쭉해줘서 조금 더 빠르게 반응할 수 있도록 만들어 놓는다. 

 

사실상 문제점이 있다.

회원가입 시간, 찾는 것을 확인하는 시간은 핵심 비즈니스 로직이 아니다. 

시간을 측정하는 로직은 핵심로직이 아니고 공통의 로직이다. 먼가 공통적으로 여러 메소드에 시간을 측정하는 것 -> 공통 관심사항이라고 말한다. 

시간을 측정하는 로직과 핵심 비지니스 로직이 섞여서 유지보수가 어렵다. 

시간을 측정하는 로직을 별도의 공통 로직으로 만들기가 매우 어려움 

전체적인 로직으로 메소드 뽑는게 어렵다. 

공통 관심 사항, 핵심 관심 사항으로 나눌 수 있다.