728x90
반응형

스프링에서의 AOP (Aspect-Oriented Programming)

 

1) 개념

 

* 스프링은 4가지 형태의 핸들러(어드바이스, Advice)를 제공.
* 스프링에서는 핸들러를 어드바이스(Advice)라는 개념으로 사용.

 

 

 

 

 * JAVA 레벨이 아닌 XML을 통해 객체를 생성하고, 인젝션(Injection)함
 

 

[코드 간략 설명] 

 - 스프링 프레임워크에서 제공해주는 핸들러(어드바이스) : MethodeInterceptor

 - MethodeInterceptor : Around Advice 사용할 때, 구현해야 하는 인터페이스.

 - MethodeInterceptor 는 InvocationHandler 와 동일한 기능을 수행하나 차이점은 InvocationHandler 의 경우에는 프록시할 타깃 객체를 InvocationHandler 인터페이스 구현 객체가 알고 있어야 하나, MethodInterceptor 의 경우에는 MethodInvocation 객체가 타깃 객체와 호출된 메소드 정보를 모두 알고 있음.
 - 인터페이스(Interface)는 스프링 프레임워크에서 알아서 감지(Auto Detecting)하여 연결해줌. 그러므로 위의 Proxy Bean 객체 XML 코드에서 aoptest.Calculator 부분(파란색)은 제거해도 무방함.
 - 스프링 프레임워크는  Invoke 대신 proceed 메서드를 호출하여 주 업무 프로세스를 호출함. / 또한 스프링 프레임워크는 핸들러(Handler) 대신 어드바이스(Advice)를 생성.

 

* 어드바이스(Advice) 란?

 - 타깃 오브젝트(Target Object)에 적용할 부가 기능을 담은 오브젝트

 - 메인 업무에 보조적으로 추가될 보조 업무.

 

 

[XML 레벨로 보조 업무 연결 코드가 이동하면서 JAVA 코드가 단순해짐]

 

 * 위의 X 표시된 코드는 주석처리하고 AOP를 활용하여 Advice 를 적용한 JAVA 코드

 * 객체의 생성과 조립을 메인 함수에서 코드에서 관리하였지만, 부가적인 파트(객체 생성과 의존성)는 XML 파일로 이동시킴.
 * XML 빈 객체의 이름 및 속성을 변경함으로써, 기존 코드에 바로 적용 가능.
 * 부가 코드와 주 코드를 분리하여 필요할 때 도킹(Docking)하여 사용 가능.
 * 위와 같은 동적 프록시(Dynamic Proxy)는 ApplicationContext의 getBean 메서드를 통해서 개체를 얻어옴.

 

 

2) 스프링 프레임워크에서의 4가지 형태의 Advice

 

 



출처: http://ooz.co.kr/213?category=818548 [이러쿵저러쿵]

728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

Spring 빈 후처리기  (0) 2018.08.29
Spring 포인트컷 조인포인트  (0) 2018.08.29
Spring 디자인 패턴  (0) 2018.08.29
Spring 동적 Proxy  (0) 2018.08.29
Spring AOP Proxy  (0) 2018.08.29
728x90
반응형

7) 패턴(Patterns)

 

패턴은 말 그대로 어떤 일정한 형태나 양식 또는 유형을 뜻함.

패턴이라는 개념은 스프링 프레임워크에 한정된 것이 아니라 개발 디자인(Development Design)에 대해 사용되는 일반적인 개념 중의 하나.

 

개발 디자인 패턴에는 다음의 2가지가 존재.

 

 * 데코레이터 패턴 :

 타깃의 코드에 손 대지 않고, 클라이언트가 호출하는 방법도 변경하지 않은 채로 새로운 기능을 추가할 때 유용한 방법. 
 핵심 코드에 부가적인 기능을 추가하기 위해서 런타임시 다이나믹하게 추가되는 프록시를 사용. 즉 동일한 인터페이스를 구현한 여러 개의 객체를 사용하는 것.
 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴. 기능 확장이 필요할 때 서브클래싱(Subclassing) 대신 쓸 수 있는 유연한 대안이 될 수 있음.
 동적으로 객체의 추가적인 기능들을 가진 객체를 덧붙여 꾸밈.


 

 * 프록시 패턴 :

 타깃의 기능 자체에는 관여하지 않으면서 접근하는 방법을 제어해주는 프록시를 이용하는 방법.

위의 2가지 패턴의 차이점은 프록시의 경우는 실제 실행될 타깃을 확장하거나 기능을 추가하는 것이 아니라, 단지 타깃에 접근하는 방법 자체를 프록시를 통하여 가능하게 하는 것이고, 데코레이터는 실행 타깃의 확장을 의미함.

 

 

데코레이터 패턴에 대한 예제 코드 : 출처 - 위키피디아 (http://en.wikipedia.org/wiki/Decorator_pattern)

 

// Windows Interface & Simple Window Class

interface Window {

    public void draw();   // draws the Window

    // returns a description of the Window

    public String getDescription();   

}

class SimpleWindow implements Window {

    public void draw() {

        // draw window

    }

    public String getDescription() {

        return "simple window";

    }

}

 

// Decorators

abstract class WindowDecorator implements Window {

    protected Window decoratedWindow; // the Window being decorated

public WindowDecorator (Window decoratedWindow)  {

        this.decoratedWindow = decoratedWindow;

    }

}

class VerticalScrollBarDecorator extends WindowDecorator {

    public VerticalScrollBarDecorator (Window decoratedWindow) {

        super(decoratedWindow);

    }

    public void draw() {

        drawVerticalScrollBar();

        decoratedWindow.draw();

    }

    private void drawVerticalScrollBar() { // draw the vertical scrollbar

    }

    public String getDescription() {

        return decoratedWindow.getDescription() + ", including vertical scrollbars";

    }

}

class HorizontalScrollBarDecorator extends WindowDecorator {

    public HorizontalScrollBarDecorator (Window decoratedWindow) {

        super(decoratedWindow);

    }

    public void draw() {

        drawHorizontalScrollBar();

        decoratedWindow.draw();

    }

    private void drawHorizontalScrollBar() { // draw the horizontal scrollbar

    }

    public String getDescription() {

        return decoratedWindow.getDescription() + ", including horizontal scrollbars";

    }

}

 

 

// Decorator Pattern Example

public class DecoratedWindowTest {

    public static void main(String[] args) {

        // create a decorated Window with horizontal and vertical scrollbars

        Window decoratedWindow = new HorizontalScrollBarDecorator (

                new VerticalScrollBarDecorator(new SimpleWindow()));

 

        // print the Window's description

        System.out.println(decoratedWindow.getDescription());

    }

}

 

윈도우에 대한 인터페이스(interface Window)와 클래스(class SimpleWindow),

그리고 수직 스크롤바가 있는 윈도우 클래스(class VerticalScrollBarDecorator), <- 데코레이터

수평 스크롤바가 있는 윈도우 클래스(class HorizontalScrollBarDecorator) <- 데코레이터

 

기존 윈도우(Simple Window) 클래스를 감싸(implements) 스크롤이 추가된 클래스를 새로 재정의함.

(기존 클래스에 장식(데코레이팅)된 형태로 클래스를 정의)

 

데코레이터 패턴의 단점 :

- 잡다한 클래스가 많아지고, 겹겹이 에워싼 형태의 구조로 구조가 복잡해지면 객체의 정체를 알기 어려움.

 

데코레이터 패턴의 장점 :

- 기존 코드는 수정하지 않고, 확장 및 추가가 가능함.

 

 

패턴의 종류에는 옵저버 패턴, 데코레이터 패턴, 프록시 패턴, 팩토리 패턴, 싱글턴 패턴, 커맨드 패턴, 어댑터 패턴, 퍼사드 패턴, 템플릿 패턴 등등 다양하며 좀 더 자세히 알고 싶은 경우에 Head First Design Patterns (저자 에릭 프리먼) 서적을 추천함.

데코레이터 패턴 위키피디아 : http://en.wikipedia.org/wiki/Decorator_pattern



출처: http://ooz.co.kr/206?category=818548 [이러쿵저러쿵]

728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

Spring 포인트컷 조인포인트  (0) 2018.08.29
Spring Advice  (0) 2018.08.29
Spring 동적 Proxy  (0) 2018.08.29
Spring AOP Proxy  (0) 2018.08.29
Spring AOP 란  (0) 2018.08.29
728x90
반응형

6) Dynamic Proxy (동적 프록시)

 

앞선 강좌에서 설명한 대로, AOP를 구현하기 위해 사용되는 프록시(Poxy) 개념은 상당히 유용한 면이 있지만, 단점도 가지고 있음.

 

* 프록시의 단점.

 

 1. 매 번 새로운 클래스 정의 필요.

  - 실제 프록시 클래스(Proxy Class)는 실제 구현 클래스와 동일한 형태를 가지고 있기 때문에 구현 클래스의 Interface를 모두 구현해야 함.

 

 2. 타깃의 인터페이스를 구현하고 위임하는 코드 작성의 번거로움.

  - 부가기능이 필요없는 메소드도 구현해서 타깃으로 위임하는 코드를 일일이 만들어줘야 함.

  - 복잡하진 않지만 인터페이스의 메소드가 많아지고 다양해지면 상당히 부담스러운 작업이 될 수 있음.

  - 타깃 인터페이스의 메소드가 추가되거나 변경될 때마다 함께 수정해줘야 한다는 부담도 있음.

 

 3. 부가기능 코드의 중복 가능성.

  - 프록시를 활용할 만한 부가기능, 접근제어 기능 등은 일반적으로 자주 활용되는 것들이 많기 때문에 다양한 타깃 클래스와 메소드에 중복되어 나타날 가능성이 높음. (특히 트랜잭션(Transaction) 처리는 데이터베이스를 사용하는 대부분의 로직에서 적용되어야 할 필요가 있음.)

  - 메서드가 많아지고 트랜잭션 적용의 비율이 높아지면 트랜잭션 기능을 제공하는 유사한 코드가 여러 메서드에 중복돼서 나타날 수 있음.

 

 

* 해결책은?

 - 다이내믹 프록시(Dynamic Prox)를 이용하는 것! (JDK Dynamic Proxy)

 

 - 다이내믹 프록시란?

    > 런타임 시 동적으로 만들어지는 오브젝트
    > 리플렉션 기능을 이용해서 프록시 생성 (java.lang.reflect)
    > 타깃 인터페이스와 동일한 형태로 생성.
    > 팩토리빈(FactoryBean)을 통해서 생성.

 

  @ 스프링의 빈은 기본적으로 클래스 이름(Class name)과 프로퍼티(Property)로 정의. 
  @ 스프링은 지정된 클래스 이름을 가지고 리플렉션을 이용해서 해당 클래스의 오브젝트를 생성.

 

참고로 스프링은 지정된 클래스 이름을 가지고 리플렉션을 이용하여 해당 클래스의 오브젝트를 생성함.

이 외에도 팩토리빈(FactoryBean)과 프록시 팩토리빈(Proxy FactoryBean)을 통해 오브젝트를 생성할 수 있음. 팩토리빈 이란 스프링을 대신해서 오브젝트의 생성 로직을 담당하도록 만들어진 특별한 빈을 뜻함.

 

[추가 정리]

데코레이터(Decorator) 또는 프록시 패턴(Proxy Pattern)을 적용하는 데에 따른 어려움은 부가기능을 구현할 클래스가 부가기능과 관계없는 메서드들도 인터페이스에 선언된 메서드라면 전부 구현해야 하는 번거로움과 부가기능과 관계된 메소드들에 구현되는 코드 중복을 들 수 있음.

 

 -> 이는 자바의 리플렉션(Reflection)에서 제공하는 다이내믹 프록시(Dynamic Proxy)를 활용하여 해결할 수 있음.

 

1. Proxy.newProxyInstance() 를 통한 프록시 생성.

2. Proxy.newProxyInstance() 를 호출할 때 전달하는 InvocationHandler 인터페이스의 단일 메소드인 invoke()에 부가 기능을 단 한번 만 구현함으로써 코드 중복 해결.


=> 다이나믹 프록시 오브젝트는 클래스 파일 자체가 존재하지 않음.

=> 빈 오브젝트로 등록 불가.

=> 팩토리빈 인터페이스 활용. (팩토리빈 인터페이스를 구현한 클래스를 빈으로 등록)



출처: http://ooz.co.kr/205?category=818548 [이러쿵저러쿵]

728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

Spring Advice  (0) 2018.08.29
Spring 디자인 패턴  (0) 2018.08.29
Spring AOP Proxy  (0) 2018.08.29
Spring AOP 란  (0) 2018.08.29
Spring IOC 컨테이너 란  (0) 2018.08.29
728x90
반응형

 5) AOP Proxy (AOP 프록시)

 

  5-1) 프록시(Proxy)란?

 

 - 클라이언트가 사용하려고 하는 실제 대상인 것처럼 위장하여 클라이언트 클라이언트의 요청을 받아주어 처리하는 대리자 역할.

프록시의 단어 자체로는 '대리인'이라는 의미를 내포하고 있음. 스프링 AOP에서의 프록시란 말그대로 대리하여 업무를 처리. 함수 호출자는 주요 업무가 아닌 보조 업무를 프록시에게 맡기고, 프록시는 내부적으로 이러한 보조 업무를 처리.

 

이렇게 함으로써, 주 업무 코드는 보조 업무가 필요한 경우, 해당 Proxy 만 추가하면 되고, 필요없게 되면 Proxy를 제거하면 됨.

보조 업무의 탈 부착이 쉬워지고, 그리하여 주 업무 코드는 보조 업무 코드의 변경으로 인해서 발생하는 코드 수정 작업이 필요 없게 됨.

 

 

 

- 프록시의 호출 및 처리 순서 -

1) Proxy 호출
2) 보조 업무 처리
3) Proxy 처리 함수(메서드) 가 실제 구현 함수(메서드) 호출 및 주 업무 처리
4) 제어권이  다시 Proxy 함수(메서드)로 넘어오고 나머지 보조 업무 처리
5) 처리 작업 완료 후, 호출 함수(메서드)로 반환.

 

  5-2) 프록시의 사용 목적

 * 클라이언트가 타깃(Target)에 접근하는 방법을 제어.

 * 타깃에 부가적인 기능을 부여.

 

 (실제 이러한 목적으로 어떻게 사용되는지는 아래에서 보자!)

 

  5-3) 프록시 구현

 

 * 먼저 사칙 연산을 위한 인터페이스(Interface)와 실제 기능을 구현한 클래스(Class) 정의.

// 사칙 연산을 정의하는 인터페이스

package aoptest;

 

public interface Calculator {

    public int add(int x, int y);

    public int subtract(int x, int y);

    public int multiply(int x, int y);

    public int divide(int x, int y);

}

 

 

// 사칙 연산을 구현하는 클래스

package aoptest;

 

public class myCalculator implements Calculator {

   

    @Override

    public int add(int x, int y) {

        return x + y;

    }

   

    @Override

    public int subtract(int x, int y) {

        return x – y;

    }

   

    @Override

    public int multiply(int x, int y) {

        return x * y;

    }

 

    @Override

    public int divide(int x, int y) {

        return x / y;

    }

}

 

 

 

// 실제 위의 사칙연산 클래스를 사용하는 예제 코드

public static void main(String[] args) {

    Calculator cal = new myCalculator(); // 다형성 

    System.out.println(cal.add(3, 4)); // add 메서드를 호출하여 3 + 4 결과를 출력

}

 

 

여기서!!

실제 사칙 연산을 하는데에 있어서 실제 소요되는 시간 측정 이라는 기능이 필요하다고 가정하자!

그렇다면 어떻게 해야 할까?

 

위의 예제 코드에서 cal.add(3, 4) 를 사용하고 있으니, 이 시간 측정을 위한 코드를 일단 myCalculator 클래스의 add 메서드에 추가하여 보자!

 

package aoptest;

 

public class myCalculator implements Calculator {

   

    @Override

    public int add(int x, int y) {

 

 // 보조 업무 (시간 측정 시작 & 로그 출력)

Log log = LogFactory.getLog(this.getClass());

StopWatch sw = new StopWatch();

sw.start();

log.info(“Timer Begin”);

 

int sum = x + y; // 주 업무 (덧셈 연산)

 

 // 보조 업무 (시간 측정 끝 & 측정 시간 로그 출력)

sw.stop();

log.info(“Timer Stop – Elapsed Time : ”+ sw.getTotalTimeMillis());

 

return sum;

    }

 

 

...

 

}

 

 

위와 같이 시간을 측정하기 위한 업무(실제 연산 업무가 아니기 때문에 보조 업무)가 add 메서드에 추가됨.

하지만, 시간 측정을 위한 이러한 코드를 add 메서드 뿐만 아니라, subtract, multiply, divide 메서드에도 추가해 주어야 하고, 설령 측정 방식이 달라지거나 로그 출력 내용이 변경 되기라도 한다면 모든 메서드를 수정해야 한다. 게다가 연산을 위한 주 업무 코드를 수정하는 것도 아니다.

 

 

그렇다면 좀 더 코드를 깔끔하게 하고, 관리도 쉽게 하고, 직관적인 프로그래밍을 위해서는 어떻게 변화를 줄 수 있을까?

바로 방금(또 이전 포스팅에서) 배운 주 업무와 보조 업무를 분리(크로스 컷팅, Cross Cutting)하고 보조 업무를 프록시(Proxy)에게 넘긴다!

 

 

AOP Proxy 를 구현한 예제 코드

// 보조 업무를 처리할 프록시 클래스 정의 (여기서는 LogPrintHandler 라 이름 지었음)

public class LogPrintHandler implements InvocationHandler { // 프록시 클래스 (핸들러)

    private Object target; // 객체에 대한 정보

 

    public LogPrintHandler(Object target) { // 생성자

        this.target = target;

    }

 

    @Override

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable   {

        Log log = LogFactory.getLog(this.getClass());

        StopWatch sw = new StopWatch();

        sw.start();

        log.info(“Timer Begin”);

        int result = (intmethod.invoke(target, args); // (3) 주업무를 invoke 함수를 통해 호출

        sw.stop();

        log.info(“Timer Stop – Elapsed Time : ”+ sw.getTotalTimeMillis());

        return result;

}

 

 

 

public static void main(String[] args) {

    Calculator cal = new myCalculator();

 

    Calculator proxy_cal = (Calculator) Proxy.newProxyInstance// (1)

        cal.getClass().getClassLoader(),  // Loader

        cal.getClass().getInterfaces(), // Interface

        new LogPrintHandler(cal)); // Handler (보조 업무를 구현하고 있는 실제 클래스)

 

    System.out.println(proxy_cal.add(3, 4));    // (2) 주 업무 처리 클래스의 add 메서드를 호출

}

 

 

 

위의 클래스와 메서드에 대한 설명.

* (1) InvocationHandler 인터페이스를 구현한 객체는 invoke 메소드를 구현해야 함. 
  해당 객체에 의하여 요청 받은 메소드를 리플렉션 API를 사용하여 실제 타깃이 되는 객체의 메소드를 호출해준다. (실제 LogPrintHandler 클래스의 invoke 메서드 내에서 method.invoke(target, args) 메서드를 호출하는데, 이는 주 업무의 메서드를 호출하는 것. main 메서드에서 Proxy.newProxyInstance 를 통해 주 업무를 처리할 클래스(myCalculator)와 보조 업무를 처리할 Proxy 클래스를 결합.

 

  - cal(변수) 실제 객체를 proxy_cal(변수) 객체에 핸들러를 통해서 전달. (LogPrintHandler())

  - getClassLoader() : 동적으로 생성되는 다이내믹 프록시 클래스의 로딩에 사용할 클래스 로더.
  - getInterfaces() : 구현할 인터페이스.
  - LogPrintHandler(cal) : 부가 기능과 위임 코드를 담은 핸들러.

Example)
 Hello proxiedHello = (Hello)Proxy.newProxyInstance(
     getClass().getClassLoader(), -> 동적으로 생성되는 다이내믹프록시 클래스의 로딩에 사용할 클래스 로더
     new Class[] {Hello.class}, <- 구현할 인터페이스
     new UppercaseHandler(new HelloTarget())); -> 부가기능과 위임코드를 담은 핸들러

* (2) 그런다음 주 업무 클래스의 메서드를 호출하게 되면 프록시 클래스의 invoke 메서드가 호출되어 자신의 보조 업무를 처리하고, 주 업무의 메서드를 호출한다.


* (3) invoke() : 메소드를 실행시킬 대상 오브젝트와 파라미터 목록을 받아서 메소드를 호출한 뒤에 그 결과를 Object  타입으로 돌려준다.

[실제 프록시 및 주 업무(타깃) 처리 순서]

 호출 및 처리 순서 : 클라이언트 ---> 프록시 ---> 타깃

 

AOP 개념은 스프링에 한정되어 사용되는 개념이 아님.

실제 위의 코드는 AOP Proxy의 구현(객체를 생성하고, 값을 주입)하는 것을 순수 JAVA 코드 단에서 처리한 것. (스프링 개념 없이)

스프링을 통해서라면 AOP 는 XML과 어노테이션(Annotation)을 통해서 더 쉽게 구현할 수 있음.

 



출처: http://ooz.co.kr/201?category=818548 [이러쿵저러쿵]

728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

Spring 디자인 패턴  (0) 2018.08.29
Spring 동적 Proxy  (0) 2018.08.29
Spring AOP 란  (0) 2018.08.29
Spring IOC 컨테이너 란  (0) 2018.08.29
Spring DI 란  (0) 2018.08.29
728x90
반응형

4) AOP

 IoC , DI 서비스 추상화와 더불어 스프링의 3대 기반 기술 중의 하나.

 

 AOP는 Aspect Oriented Programming 의 약자인데 그 의미는 무엇인가?

 

 

  4-1) Aspect Oriented Programming의 의미는?

  -> Aspect 를 만드는 프로그램 방법.
  -> Aspect 지향 프로그램.

 

  우리말로 풀이하면 관점 지향 프로그래밍

 

   * 여기서 Aspect는 측면 또는 관점이라는 의미로 볼 수도 있고, 부가적인 업무를 의미하기도 함.

 

 “전통적인 객체지향기술의 설계방법으로는 독립적인 모듈화가 불가능한 트랜잭션 경계설정과 같은 부가 기능을 어떻게 모듈화 할 것인가”
 “트랜잭션(핵심 기능과 부가 기능)의 분리”

 

횡단 관심사와 이에 영향 받는 객체 간의 결합도를 낮추는 것!

 

AOP(관점 지향 프로그래밍)는 왜 사용하는가?

- 주 업무가 아닌 부가적인 업무가 강한 응집력을 가지고 있는 경우, 소스 관리 및 개발 업무 진행의 복잡해지고, 어려워짐.
- 즉 서비스 추상화가 어려워짐. 이러한 문제를 해결하기 위한 프로그래밍 기법으로 OOP(Object Oriented Programming)의 보완적 개념.

 

 - 횡단 관심사와 이에 영향 받는 객체 간 결합도를 낮추는데 목적이 있다. 쉽게 말해 클래스들이 공통으로 갖는 기능이나 절차 등을 하나의 것으로 묶어 빼내어 별도로 관리하려는 목적.

 - 이러한 부가적인 업무의 예로 로그인(Login), 트랜잭션(Transaction), 보안(Security), 캐싱(Caching)과 같은 내부 처리(비지니스, Business) 작업이 있다.

 

AOP는 메인 프로그램의 비즈니스 로직으로부터 2차적 또는 보조 기능들을 고립시키는 프로그램 패러다임(관점 지향 프로그래밍 패러다임)이며, 애플리케이션의 핵심적인 기능에서 부가적인 기능을 분리해서 애스펙트(Aspect)로 정의하고 설계하여 개발하는 방식.

 

위에서도 언급했지만, 스프링 프레임워크에서의 애스펙트(Aspect)란

 - 주업무가 아닌 업무.
 - 보조업무 : 로그, 트랜잭션, 보안처리.

를 의미함.

 

 

 4-2) AOP의 구현이란?

- 주 업무가 아닌 보조적인 업무를 주 업무를 처리하는 코드에서 분리하는 것.

 

 

 4-3) AOP의 장점은 무엇인가?
- 전체 코드 곳곳에 흩어져 있는 다양한 관심 사항이 하나의 장소로 응집.
- 여타 서비스 모듈이 자신의 주요 관심 사항(또는 핵심 기능)에 대한 코드만 포함하고 그 외의 관심 사항은 모두 Aspect로 옮겨지므로 코드가 깔끔해지고, 가독성이 높아짐.

 

참고 : 관점지향프로그래밍(AOP)이란?

링크 : http://ko.wikipedia.org/wiki/%EA%B4%80%EC%A0%90_%EC%A7%80%ED%96%A5_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

 

관점지향프로그래밍 패러다임 : 이것은 횡단관심사의 분리를 허용하고, 관점 지향 소프트웨어 개발의 기초를 형성하여 모듈화를 증가시키려 한다. 관점 지향 소프트웨어 개발이 모든 엔지니어링 분야에 관련되는 반면에, 관점 지향 프로그래밍은 소스코드 레벨에서 관심사들의 모듈화를 지원하는 프로그래밍 기술과 툴들을 포함한다.

관점 지향 프로그래밍은 프로그램을 명확한 부분으로 나누는 것을 수반한다. 모든 프로그래밍 패러다임은 이들 관심사들을 구현, 추상화, 구성하는 추상적 개념을 제공하는 분리되고, 독립적인 통로들을 통해 Grouping의 같은 레벨과 관심사들의 캡슐화(Encapsulation)를 지원한다. 그러나 어떤 관심사들은 구현의 이런 형태를 거역하고, 이들이 프로그램 내에서 다중 추상적 개념들에 영향을 끼치기 때문에 횡단관심사(cross-cutting concerns)라고 불린다.

 

 

 4-4) AOP의 시각화

 * 핵심적인 기능에서 부가적인 기능을 분리하여 애스팩트라는 독특한 모듈로 만들어서 설계하고 개발하는 방법.

 

* 독립 애스펙트를 이용한 부가기능의 분리와 모듈화. (애스팩트를 모두 독립시킴) - 위의 그림 참조

 

 

 4-5) AOP는 실제 코드에서 어떻게 처리되는가?

 

 

 기존의 개발 방식은 보조 업무를 담당하는 코드가 주 업무 코드 사이사이에 포함되어 있음.

 

 보조 업무가 주 업무 코드에 포함될 때에는 다음과 같은 일이 발생.
  * 동일한 작업 반복.
  * 보조 업무의 작업 코드가 변경될 시, 해당 보조 업무를 사용하는 모든 주 업무 코드의 소스 수정 필요.
  * 주 업무 코드보다 더 많은 양의 보조 업무 코드 – 특히 DB 객체 생성 및 접속, 예외 처리, DB 닫기 등.

 AOP는 이러한 보조 업무 코드를 주 업무 코드에서 별도로 분리하여 작성하고, 필요할 때에만 도킹(Docking)하여 사용하는 것은 어떨까? 하는 발상에서 나온 개념.

 

 * 여기서 핵심 코드(핵심 관심사)는 Core(Primary) Concern.

 * 부가/보조 업무 코드(횡단 관심사)는 Cross-Cutting Concern.

 

 위의 오른쪽 그림에서 보듯이 주 업무에서 보조 업무를 횡단으로 잘라내었다는 의미로 Cross-Cutting 이라 불림.

 

-------------------------------------------------------------------------------------------------------------------------------

 AOP에 대한 개념과 다룰 범위가 좀 더 넓은데요. 다음 포스팅에서는 스프링 프레임워크에서 실질적으로 AOP를 적용하여 사용하는 기술인 AOP 프록시(AOP Proxy)에 대해 알아보도록 하겠습니다.



출처: http://ooz.co.kr/193?category=818548 [이러쿵저러쿵]

728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

Spring 동적 Proxy  (0) 2018.08.29
Spring AOP Proxy  (0) 2018.08.29
Spring IOC 컨테이너 란  (0) 2018.08.29
Spring DI 란  (0) 2018.08.29
Spring 프레임워크 란  (0) 2018.08.29

+ Recent posts