공부하는 개발 블로그

• core concern(business logic)
• cross-cutting concern(system layer logic. 실제 business logic 이외)

을 분리하는 프로그래밍 패러다임.

로깅, data validation, DB transaction 처리 등은 여러 곳에서 이용되지만, 분명히 프로그램의 핵심 로직은 아니다.

그렇다보니 Object가 하나의 책임과 역할을 수행하는 OOP를 적용하기에는 불편하고,
프로그램 로직과는 별개로 관리하는 것이 편리하다.

간단한 예시를 생각하보자.
- 로깅을 하기 위해서 모든 함수의 parmater로 logger를 포함해야한다거나,
- 모든 함수에서 사용자의 권한을 확인하는 코드를 호출해야한다면,

중복 코드로 가독성이 떨어지고, 프로그램 로직과 부차적인 코드를 구별해서 관리하기가 어렵다.

로깅 형식을 바꾼다던가, type을 변경하려고만 해도 여기저기 흩어져있는 관련된 코드를 모두 수정해야한다.

AOP에서는 이처럼 여러 곳에 사용되는(흩어져서 존재하는) 기능을 모듈화하고,
이용되는 상황을 정의? 조건화?하여 반복 코드를 줄인다.

wikipedia의 아래 설명이 제일 믿을만하고 명료했다.

An aspect of a program is a feature linked to many other parts of the program, but which is not related to the program's primary function.
(https://en.wikipedia.org/wiki/Aspect_(computer_programming))

This allows behaviors that are not central to the business logic (such as logging) to be added to a program without cluttering the code, core to the functionality.
(https://en.wikipedia.org/wiki/Aspect-oriented_programming)

(한 페이지 설명: https://www.simplilearn.com/spring-aop-tutorial)

- 이해하기가 조금 어렵고,

- control flow를 관리하기 어려워 GOTO 보다 나쁘다는 평가도 있다.

- 여러 곳에 흩어져있는 코드를 하나로 관리하다보니, 하나를 수정했을 때 전체 영향을 미칠 수 있다.

* 비고

AOP의 개념보다도, 이 문제를 해결하기 위해서 AOP를 사용하는 것이 맞는가? 라는 판단을 내리는 게 더 어려운 것 같다.

Cross-cutting concerns의 예시

• Business rules
• Caching
• Code mobility
• Data validation
• Domain-specific optimizations
• Error detection and correction
• Internationalization and localization which includes Language localisation
• Information security
• Logging
• Memory management
• Monitoring
• Persistence
• Product features
• Real-time constraints
• Synchronization
• Transaction processing
• Context-sensitive help