Spring AOP : 관점 지향 프로그래밍

저번 포스팅(iworldt.tistory.com/13)에 이어, 이번 포스팅 역시 미디엄(meduim.com)에서 본 글을 번역해보는 포스팅이다. 저번 포스팅의 주제는 스프링 프레임워크의 의존성 주입이었다.

이번 포스팅의 주제는 스프링 프레임워크의 관점지향 프로그래밍이다. 주제는 What is Spring AOP? 이다. 

(medium.com/@raffai.89.zoltan/what-is-spring-aop-f5191cc1b54c)이 원본이다!

우리가 Aspect Oriented Programming, 즉 관점 지향 프로그래밍에 대한 정보를 발췌할 수 있는 부분의 번역만 작성하도록 하겠다. 물론 나의 주관적인 해석이 들어가 있으므로, 나의 해석을 참고하여 단어들을 검색하며 정확한 정보를 찾아갈 수 있기를 바란다. 또한, 틀린 부분이 있다면 알려주신다면 감사하겠다!

What is Aspect Oriented Programming(AOP)?

Aspect-Oriented programming is a programming paradigm which tries to solve the problems of cross-cutting concerns. Aspect-oriented Programming (AOP) complements Object-oriented Programming (OOP) by providing another way of thinking about program structure.

The key unit of modularity in OOP is the class, whereas in AOP the unit of modularity is the aspect.

관점지향 프로그래밍이 무엇인가?

관점 지향 프로그래밍은 횡단관심(cross-cutting concerns) 문제를 해결하도록 하는 프로그래밍 패러다임이다. 관점지향 프로그래밍은 객체지향프로그래밍(Object-oriented Programming)을 프로그램 구조에 대해 또다른 관점을 제공함으로써 보완한다.

객체지향프로그래밍의 모듈화의 핵심 유닛은 클래스인 반면에 관점지향 프로그래밍의 모듈화의 유닛은 관점이다.

우선, cross-cutting concerns(횡단관심)에 대해 알아보자. 이것의 반대는 core concerns(핵심 관심)이다. 핵심관심란, 객체지향 프로그래밍에서 하나의 클래스로 표현되고 있는 관심사이다. 하나의 기능이라고 이해하면 편할 것이다. 그러나 횡단관심은, 여러 핵심관심 클래스들에 걸쳐 구현되고있는 관심으로 클래스들을 가로지르고 있어 횡단 관심이라고 표현한다. 이 횡단관심은 여러 클래스에서 필수적이고, 그래서 반복되는 코드이지만 핵심코드는 아닌 관심이다. 이것의 예는 뒤에서 살펴본다.

In a more simpler word, it helps us to refactor the different necessary repeating codes into different modules. Which gives us the benefit that we can maintain these functionalities in one single place, instead of it writing down every time.

더 간단히 설명하면, 이것은 서로다른 필수적인 반복 코드를 다른 모듈로 코드의 구조를 재조정하도록 돕는다. 우리에게 주는 이점은 매번 계속 써내려가는 대신 하나의 독립된 공간에서 기능들을 유지보수할 수 있다는 것이다.

여기서 말하는 서로다른 필수적인 반복 코드가 바로 횡단관심이다. 여러 클래스에 걸쳐 구현된 횡단관심을 하나의 모듈로 구현하여 구조를 재조정한다는 것이다.

This approach will result in a much more maintainable code, which clears the business logic from the most confusion factor. We separate these functionalities along different aspects.

An aspect is a modularization of a concern that cuts across multiple classes. Unified logging or transaction management can be a good example of it.

이 접근(관점지향)은 더많은 유지보수가능한 코드를 만들어내는데, 대부분의 혼란요인으로부터 비즈니스 로직을 깨끗하게 한다. 우리는 이러한 기능들을 서로다른 관점들로 분리한다.

한 관점은 여러 클래스에 걸친 한 관심사의 모듈화이다. 통합 로깅 또는 트랜잭션 관리가 좋은 예시이다.

유지보수가능하다는 것은, 횡단관심을 하나의 모듈로 관리함으로써 서로에게 끼치는 영향을 줄임으로써 코드의 지속적인 관리를 쉽게 한다는 뜻으로 볼 수 있다.  여러 클래스에 걸친 한 관심사의 모듈화 , 즉 하나의 횡단관심을 한 관점 으로 보는 것이 바로 관점지향 프로그래밍이다.

How AOP works on a large scale

If you have a system that contains several packages and classes and you do not use AOP that aspects such as Tracing, Transactions, and Exception Handling, have to implement in every class and every method. This results in two problems:

큰 범위에서 AOP가 동작하는 방식

cross-concern 횡단관심

만약 당신이 수많은 패키지들과 클래스들을 포함한 시스템을 갖고있고 Tracing, Transactions, Exception Handling과 같은 관점의 AOP를 사용하지 않는다면, 모든 클래스와 모든 메소드마다 구현해야한다. 이것은 두 가지의 문제를 만든다.

• Code Tangling: Each class, each method contains Tracing, Transactions, and Exception Handling, and also Business Logic. In a tangled code it is often hard to see what is actually going on in a method.
• Code Scattering: Aspects such as Transactions are scattered throughout the code and not implemented in a single specific part of the system.

 

• Code Tangling(코드 엉킴) : 각 클래스와 각 메소드는 Transactions, Exception Handling과 비즈니스 로직 또한 포함하고 있다. 이렇게 엉킨 코드는 메소드에서 실질적으로 어떤 일이 수행되는지 알기 힘들다.

하나의 메소드에는 하나의 기능, 하나의 변경이유만 존재해야 한다. 횡단관심과 핵심관심이 공존하면 이 프로그래밍 원칙을 어기게 된다.

• Code scattering(코드 산란) : 트랜잭션과 같은 관점들은 모든 코드에 걸쳐 분산되고 시스템의 특정한 독립된 부분에 구현되지 않는다.

Using AOP, allows you to solve these problems. So what AOP does is it takes all the Transaction code, and puts it into a Transaction Aspect, then it takes all the Tracing Code and puts that into an Aspect and finally, all the Exception Handling is also put into an Aspect.

Afterward, there will be a clean separation between the Business Logic and all those additional aspects.

AOP는 이런 문제들을 해결해준다. AOP가 하는 것은 모든 트랜잭션 코드를 가져가 트랜잭션 관점에 모으고나서, 모든 트레이싱 코드을 가져가 한 관점으로 모으고, 최종적으로 모든 예외처리 또한 한 관점에 놓아진다.

그 후에 비즈니스 로직과 모든 추가적인 관점들 사이에 분명한 분리가 생긴다.

대표적인 횡단관심의 예가 바로 트랜잭션, 트레이싱, 예외처리이다. 이들은 모든 클래스에서 구현되어야 하지만, 그 클래스의 핵심적인 기능은 아닌 것들이다. 이러한 횡단관심을 한 관점으로 보고 하나의 모듈로 구현하여 비즈니스로직, 즉 실제 기능구현코드와 구분한다.