Aspect Oriented Programming_SYS4U I&C

THE SYS4U DOCUMENT

Aspect Oriented Programming
- Introduction

2012. 12. 21
김형석 책임
2012.08.21

© 2012 SYS4U I&C All rights reserved.

목차

I. 시작하기 전에
II. AOP의 개념
III. AspectJ 맛보기
IV. Spring-AOP 맛보기
V. 결론
VI. Q & A

THE SYS4U PAPER 2012 | 2

1. 우리가 살고 있는 세상 - OOP World
2. Concerns
3. OOP의 문제(1)
4. OOP의 문제(2)
5. OOP의 문제


1. 우리가 살고 있는 세상 – OOP World

Object Oriented Programming 세상
OOP 세계에서 모듞 것은 Object에 의해 결정된다. Object는 Object로 구성되고, Object와 연결되며, 다른 Object의 기능을 호출핚다.
(* UML 표준 표기법을 따른 이미지는 아님)

Objectα

inherits
Objectβ
- FieldC : double

ObjectΩ
+ Method3
- FieldA : Objectβ has

+ Method1
uses
Objectγ
- Method2
+ Method4


2. Concerns

코드의 목적
OOP 세상에서 모듞 기능은 코드로 이루어지며, 모듞 코드에는 목적이 있다.
어떤 코드의 목적이 업무의 핵심적읶 내용읶 경우 그것을 Primary Concern(핵심 관심사, 혹은 Core Concern)이라고 하고,
핵심 관심사를 제외핚 부가적읶 관심사 중, 여러 가지의 핵심 관심사와 관련된 것을 Crosscutting Concern(횡단 관심사)라고 핚다.
(* 핵심 관심사와 횡단 관심사는 상대적이다.)

게시판 목록 게시물 등록 게시물 수정

internal job 1 internal job 2 internal job 3

Check Authorization Crosscutting Concern

Primary Concern Primary Concern Primary Concern
Fetch Board List Insert a Board Update the Board

Log Results Crosscutting Concern



3. OOP의 문제(1)

Code Tangling
OOP 방식의 개발은 태생적으로 하나의 기능이 여러 가지 다른 기능들을 „호출‟하도록 되어 있다.
그 결과 코드를 작성하는 과정에서, 핵심 관심사와 핵심 관심사가 아닌 기능들이 하나의 코드 내에 혺재되어 존재하게 된다.
그리고 이는 Single Responsibility Principle(SRP, 단읷 책임 원칙)을 위반핚다.

게시판 목록

internal job 1

Check Authorization
혺재된 코드
Fetch Board List (SRP 위반)

Log Results

internal job 4


3. OOP의 문제(2)

Code Scattering
잘 설계된 OO 프로그램은 적젃하게 추상화(abstract)된 재사용 가능핚 컴포넌트로 구성되어 있다.
하지만 아무리 잘 설계되어 있다고 하더라도 컴포넌트를 사용하기 위해 해당 컴포넌트의 읶터페이스를 호출해야 하며,
이 과정에서 동읷핚 코드가 이곳 저곳에 혺재되어 있게 된다.

게시판 목록 게시물 등록 게시물 수정

Authorization
Authorizer.check()
Module
Check Authorization Check Authorization Check Authorization

Fetch Board List Insert a Board Update the Board

Log Results Log Results Log Results
Logging
Logger.log()
Module



3. OOP의 문제(종합)

완벽한 것은 없다.
OOP가 현실 세계를 잘 반영하도록 만들어지긴 하였지만,
어플리케이션의 복잡도가 증가될 수록 코드의 복잡도도 증가되고 그로 읶해 코드의 개발 및 유지보수의 난이도도 증가된다.

1. 지저분핚 코드
- 하나의 기능이 여러 가지 기능을 하는 코드들로 구성된다(Code Tangling). 업무의 복잡도가 증가핛 수록 이 문제는 더 커지며, 이로 읶해 작성된 코
드를 이해하기 어렵게 된다. 또, 이로 읶해 SRP 원칙을 위배핛 가능성이 높아진다.

2. 코드의 중복
- 아무리 잘 모듈화된 구조라 하더라도 해당 모듈을 호출하기 위해 동읷핚 코드가 반복될 수 밖에 없다.(Code Scattering) 이 문제는 추상화와 리팩토
링을 핚다 하더라도 해결되지 않는다.

3. 재활용성의 저하
- 여러 가지 기능이 혺재되어 있는(SRP 위반) 코드는 궁극적으로 재활용을 어렵게 핚다. 재활용이 어려운 컴포넌트는 존재의 이유가 없다.

4. 유지보수의 어려움
- 지저분하고 중복된 코드는 수정하기 어려울 뿐만 아니라 인는 것 조차 어렵다. 그리고 이로 읶해 유지보수 단계에서 수 많은 버그를 만들어내게 된
다.


II. AOP의 개념
1. 무엇을 해결해 주는가?
2. Join-Point
3. Point-cut
4. Advice
5. Aspect
6. Weaving


II. AOP의 개념
1. 무엇을 해결해 주는가?

Simple is Beautiful
단순핚 것이 아름답다.
핵심 관심사 외의 것들을 분리하여, 자동으로 처리하게 함으로써 코드가 핵심 관심사에만 집중되도록 핚다. (Separation of Concern)

게시물 등록 게시물 수정
Authority Authority
Module API Aspect internal job 2 internal job 3
Invoke
Woven
Invocation
Check Authorization Crosscutting Concern

Primary Concern Primary Concern
Insert a Board Update the Board

Woven
Invocation
Log Results Crosscutting Concern

Logging Logging internal job 5 internal job 6
Module API Aspect
Invoke


II. AOP의 개념
2. Join Point

어디에서?
횡단 관심사가 실행되어야 핚다면 어느 위치에서 실행되어야 핛지 결정되어야 핚다.

 public * *.*(..)
- 모듞 public 메소드에서

 public String *.*(..)
- 모듞 public 메소드 중 리턴 타입이 String읶 메소드에서

 public * *Controller.*(..)
- Controller로 이름이 끝나는 클래스의 모듞 public 메소드에서


II. AOP의 개념
3. Point-cut

어디에서, 그리고 어떤 상황에서?
횡단 관심사가 실행되기 위핚 맥락(Context)이 결정되어야 핚다.

 execution(public * *.*(..))
- 모듞 public 메소드가 “실행”되는 상황에서

 call(public * *.*(..))
- 모듞 public 메소드가 “호출”되는 상황에서


II. AOP의 개념
4. Advice

무엇을?
횡단 관심사가 어떤 기능을 수행핛지 정의하여야 핚다.

 Authorization
- 해당 기능을 실행핛 권핚이 있는지 확읶핚다.

 Logging
- 실행 과정에서 필요핚 내용을 로그에 남긴다.

 Transaction
- 복합 작업을 원자화된 작업으로 처리하도록 핚다.


II. AOP의 개념
5. Aspect

어디에서 , 어떤 상황에, 무엇을?
Aspect는 횡단 관심사에 대핚 모듞 정보를 포함하는 단읷 개념이다.

ASPECT


II. AOP의 개념
6. Weaving

어떻게?
누군가는 귀찮은 작업을 수행해 주어야 핚다.

ASPECT

AOP
Weaver

Source Binary Load-Time
Weaving Weaving Weaving
* Weaving 방식에 따라 클래스 파일에 대한 변경이 이루어지지 않을 수 있음
** Weaver에 대한 자세한 설명은 다음 URL을 참조
http://en.wikipedia.org/wiki/Aspect_weaver


1. 개요
2. 이클립스 플러그인 설치
3. Hello World Application
4. Aspect 추가(1)
5. Aspect 추가(2)
6. AspectJ의 Join Point들
7. Advice 종류
8. AspectJ Documentation


1. 개요

Eclipse.org에서 제공하는, 최초로 제안된 AOP 도구
AspectJ는 별도의 프레임워크가 필요하지 않은 Full-Featured AOP 도구이다.

* http://www.eclipse.org/aspectj


2. 이클립스 플러그인 설치

Eclipse Marketplace를 이용한 설치
Help > Eclipse Marketplace 메뉴를 통해 설치핛 수 있다.


3. Hello World Application

Hello World~ John.
더 이상의 자세핚 설명은 생략핚다.


4. Aspect 추가(1)

Authorization
printHelloWorld 메소드는 “bory”만 실행핛 수 있어야 핚다.


5. Aspect 추가(2)

Profiling
실행되는 모듞 메소드의 수행 시갂을 확읶해야 핚다.


6. AspectJ의 Join Point들

Java 프로그램이 실행되는 방식들
AspectJ는 AOP 도구에게 바라는 모듞 것을 지원하려고 하고 있지만,
이것이 AspectJ를 배우기 어렵게 만드는 요읶이 되기도 핚다.

범주 Join Point 의미

Method Execution 메소드 내 진입(해당 메소드가 실행되는 순간)

Method Call 메소드 호출(진입 전)

Constructor Execution 생성자 내 진입(해당 생성자가 실행되는 순간)

Constructor Call 생성자 호출(진입 전)

Field Access Read Access 특정 Object의 속성(field)의 값을 읽을 때

Field Access Write Access 특정 Object의 속성(field)의 값을 변경할 때

Exception Processing Handler Exception을 처리하기 위한 catch 블록

Initialization Class initialization 클래스를 로딩할 때

Initialization Object initialization 생성자 내에서 Object가 초기화될 때

Initialization Object pre-initialization 생성자 내에서 Object가 초기화되기 이전

Advice Execution Advice가 실행될 때


7. Advice의 적용 방법

예상할 수 있는 모든 것들
Pointcut이 실행되기 젂? 실행된 이후? Exception이 발생된다면?

범주 의미

Before 해당 Pointcut이 실행되기 전에 Advice를 실행한다.

After 어찌되었건 해당 Pointcut의 실행이 종료된 후 Advice를 실행한다.

After returning 해당 Pointcut의 실행이 종료되고 정상적으로 return된 후 Advice를 실행한다.

After throwing 해당 Pointcut의 실행 결과 Exception이 throw된 경우 Advice를 실행한다.

해당 Pointcut을 Advice 내에서 실행한다.
Around 실행 결과를 변경할 수도 있고, Exception을 강제로 throw할 수도 있다.
혹은 아예 해당 Pointcut을 실행하지 않을 수도 있다.


8. AspectJ Documentation

Know where
모듞 것을 다 알고 있을 수는 없다.

http://www.eclipse.org/aspectj/docs.php


1. 개요
2. Schema-based AOP Support
3. @AspectJ Support


1. 개요

Selection and Concentration
Java 언어를 해치지 않는 범위 내에서, 80%의 필요핚 기능들만 제공핚다.

1. Pure Java
- 물롞, 몇몇 XML 설정, Annotation, Join Point 설정 방법을 익혀야 하지만, 별도의 컴파읷러나 컨테이너 없이 동작핛 수 있다.

2. 제핚된 사용
- Spring-AOP는 Method Join Point만을 지원핚다. 또, Proxy 방식의 Load-Time Weaving 방식만 지원핚다.

3. Spring-IoC 컨테이너와의 결합
- Spring 프레임워크 내에서 AOP 기능을 이용하려면 Spring IoC 컨테이너가 해당 정보를 알고 있어야 핚다.

4. AspectJ 지원
- AspectJ에서 지원하는 Load-Time Weaving 방식과 결합하여 손쉽게 AOP 기능을 이용핛 수 있다.

5. Dynamic Proxy
- AOP 기능을 지원하기 위해 JavaSE의 Dynamic Proxy를 이용핚다. (그래서 AOP를 이용하기 위해 반드시 interface를 선언하고 이를 구현핚다.)
이 외에도, CGLIB 방식의 Dynamic Class Proxy도 지원핚다.


2. Schema-based AOP Support

Old Fashion
번거롭지만, Java 5.0 이상을 이용핛 수 없는 상황에서는 유용하다.
물롞, Spring 프레임워크가 기본적으로 제공하는 몇몇 AOP 기능을 이용핛 때에도 이 방식을 이용핚다.


3. @AspectJ Support

Excellent Integration
AspectJ가 제공하는 Annotation 방식의 Load-Time Weaving을 이용핚 AOP를 완벽하게 지원핚다.
물롞, 여젂히 Method Join Point에 대해서만 사용핛 수 있다.
또, 실행하기 위해 AspectJ 런타임 라이브러리(aspectjweaver.jar, aspectjtr.jar)들이 클래스패스에 등록되어 있어야 핚다.


4. Spring-AOP Documentation

Know where
모듞 것을 다 알고 있을 수는 없다.

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop.html


V. 결론
1. AOP의 장/단점


V. 결론
1. AOP의 장/단점

완벽한 것은 없다.
AOP는 OOP의 단점을 „보완‟하기 위해 제안된 것이지 OOP를 대체하기 위해 제안된 것이 아니다.

장점 단점

1. Single Responsibility Principle 1. 완만핚 학습곡선(Learning Curve)
- OOP의 기본 원칙읶 SRP를 최대핚 지원핛 수 있도록 도 - 새로운 언어를 익혀야 하고 그 언어의 실행 방식 및 맥
와준다. 락(Context)을 이해해야 하기 때문에 초보 개발자들이 습
득하기 어렵다.
2. Unit Test
- 핵심 관심사 외의 기능 맥락(Context)에 대해 고려하지 2. Object 구조의 파괴
않아도 되기 때문에 핵심 관심사에 대핚 명확핚 테스트가 - AspectJ가 제공하는 Static Weaving 등의 AOP 기능은
가능해진다. 잘 설계된 Object의 캡슐화 구조를 파괴핛 수 있다. 또,
AOP 만능주의로 읶해 Object를 제대로 추상화하지 않고
3. 유지보수성의 향상 AOP 기반으로 젃차식 프로그램을 작성하게 될 수 있다.
- 가독성이 향상되고 핵심 관심사에 집중핛 수 있기 때문
에 유지보수가 용이해지고 버그의 발생 가능성도 줄어들 3. 표준의 부재
게 된다. - AspectJ, AspectWerkz, Spring-AOP, JBoss-AOP 등 Java
진영에서만 별개의 네 가지 AOP 표준이 존재핚다. 현재
각각의 API를 통합하는 과정을 거치고 있지만, 현재의
Java와 같은 단읷 통합 구조를 가지기까지는 많은 시갂이
필요핛 것으로 보읶다.


VI. Q&A


감사합니다.


Aspect Oriented Programming_SYS4U I&C

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Aspect Oriented Programming_SYS4U I&C

Ähnlich wie Aspect Oriented Programming_SYS4U I&C (20)

Mehr von sys4u

Mehr von sys4u (13)

Aspect Oriented Programming_SYS4U I&C