AOP(Aspect Oriented Programming)
관점 지향 프로그래밍의 약자이다.
여기 4명의 개발자들이 있다.
구매 개발자: 구매 버튼 클릭 → 로그인 체크 → 구매 완료
장바구니 개발자: 장바구니 버튼 클릭 → 로그인 체크 → 아이템 삭제 완료
찜하기 개발자: 찜하기 버튼 클릭 → 로그인 체크 → → 찜하기
로그인 체크 개발자: 로그인 체크 개발
각 개발자는 자신이 구현해야 하는 로직에만 관심이 있다.
⇒ 다 관심사가 다름!
관심사는 다르지만 모두 로그인을 체크하는 로직을 공통적으로 가진다.
로그인 체크 부분을 각자 구현하면 코드의 중복이 생기므로 로그인 체크 개발자가 하나 개발해서 모듈화 시키고, 다른 모든 개발자들이 그 모듈을 사용하는 형태가 바람직할 것이다.
💡 4가지 경우는 서비스 로직을 바라보는 관점 자체가 다른 것
로그인 개발자가 개발한 클래스를 스프링 빈으로 등록하면 나중에 다른 개발자가 사용하고자 할 때 주입받아서 사용할 수 있을 것이다.
→ 스프링은 이미 이 경우를 고려했다.
주입받는 코드 또한 중복이므로 스프링에서는 @Before, @After 어노테이션으로 원하는 곳에 공통 관심 사항을 적용할 수 있다.
객체지향 프로그래밍과는 대립되는 개념일까?
아니다.
오히려 객체지향이기에 관점지향이 매끄럽게 구현될 수 있다고 생각한다.
예시에서처럼 공통 관심사를 구현한 모듈을 사용하려면 객체지향 원칙을 지켜 모듈을 구현하는 것이 효율적일 것이다.
객체지향 원칙을 지킨다고 하면,
다른 파트의 개발자들은 로그인 체크 모듈의 인터페이스를 사용할 것이다.
자세한 구현 로직은 알 필요가 없다.
로그인 체크 구현 로직이 변경되어도 모듈을 사용하는 다른 파트는 영향을 받지 않는다.
결과적으로 관점지향에도 효과적일 것이다.
원하는 곳에 공통 관심사 적용 예시
대표적인 예시로 @Transactional이 있다.
롤백, 커밋 등등.. 여러가지 트랜잭션 관련 관점을 →
@Transactional어노테이션으로 제공
