애스펙트 지향 프로그래밍

Aspect-oriented programming

컴퓨팅에서 AOP(Aspect-oriented Programming)는 교차 관심사를 분리함으로써 모듈성을 증가시키는 것을 목적으로 하는 프로그래밍 패러다임입니다.코드 자체를 수정하지 않고 기존 코드에 동작을 추가(어드바이스)하는 대신 "함수의 이름이 'set'으로 시작할 때 모든 함수 호출을 기록"과 같은 "포인트컷" 사양을 통해 수정되는 코드를 별도로 지정함으로써 이를 수행합니다.이를 통해 비즈니스 로직의 핵심이 아닌 동작(로그 등)을 기능에 코드 코어를 복잡하게 하지 않고 프로그램에 추가할 수 있습니다.

AOP에는 소스 코드 수준에서 관심사의 모듈화를 지원하는 프로그래밍 방법 및 도구가 포함되며, 측면 지향 소프트웨어 개발은 전체 엔지니어링 분야를 의미합니다.

애스펙트 지향 프로그래밍에서는 프로그램 로직을 별개의 부분(이른바 관심사, 기능의 응집력 있는 영역)으로 분할해야 합니다.거의 모든 프로그래밍 패러다임은 이러한 관심사를 구현, 추상화 및 구성하는 데 사용할 수 있는 추상화(예: 기능, 절차, 모듈, 클래스, 방법)를 제공함으로써 관심사를 별도의 독립적 실체로 그룹화하고 캡슐화하는 것을 지원한다.일부 우려 사항은 프로그램에서 여러 추상화를 "간단"하고 이러한 형태의 구현에 도전합니다.이러한 우려를 교차 우려 또는 수평 우려라고 합니다.

로깅 전략은 반드시 시스템의 모든 로깅 부분에 영향을 미치기 때문에 로깅은 크로스컷 우려의 예입니다.따라서 로깅은 로깅된 모든 클래스 및 메서드를 크로스컷합니다.

모든 AOP 구현에는 각 문제를 한 곳에 캡슐화하는 교차 표현식이 있습니다.구현 간의 차이는 제공된 구성의 전력, 안전성 및 사용성에 있습니다.예를 들어, 타입 세이프티 또는 디버깅을 크게 지원하지 않고 제한된 형식의 크로스 컷을 표현하는 방법을 지정하는 인터셉터입니다.Aspect J에는 이러한 표현들이 다수 있으며, 그것들을 특별한 클래스인 Aspect에 캡슐화합니다.예를 들어, 애스펙트는 포인트 컷이라고 불리는 수량화 또는 쿼리로 지정된 다양한 조인 포인트(프로그램의 포인트)에 어드바이스(추가 동작)를 적용함으로써 베이스 코드(프로그램의 비 아스펙트 부분)의 동작을 변경할 수 있다.또한 멤버나 부모 추가와 같은 이진 호환 구조를 다른 클래스에 변경할 수도 있습니다.

역사

AOP는 몇 가지 직접적인 선행 요소 A1과 A2를 [1]가지고 있다: 리플렉션과 메타 오브젝트 프로토콜, 주제 지향 프로그래밍, 합성 필터 및 적응 프로그래밍.[2]

Gregor KiczalesXerox PARC동료들은 AOP의 명시적 개념을 개발하였고, 이를 따라 AspectJ AOP를 Java로 확장하였습니다.IBM의 연구팀은 언어 설계 접근 방식보다 도구 접근 방식을 추구했으며, 2001년 광범위한 사용을 볼 수 없는 Hyper/J 및 우려 사항 처리 환경제안했습니다.

이 문서의 예에서는 AspectJ를 사용합니다.

Microsoft Transaction Server는 AOP의 [3][4]첫 번째 주요 애플리케이션으로 간주되며 Enterprise JavaBeans가 그 뒤를 잇습니다.

동기 부여 및 기본 개념

일반적으로 애스펙트는 코드로 분산되거나 얽혀 있기 때문에 이해 및 유지보수가 어렵습니다.기능(로깅 등)이 전혀 관련되지 않은 시스템, 다른 소스 언어 등 기능을 사용할 수 있는 많은 관련되지 않은 기능에 의해 분산되어 있습니다.즉, 로깅을 변경하려면 영향을 받는 모든 모듈을 변경해야 합니다.측면이 표현되는 시스템의 주요 기능뿐만 아니라 서로 엉켜 있습니다.즉, 하나의 관심사를 바꾸는 것은 얽힌 모든 관심사를 이해하거나 변화의 효과를 추론할 수 있는 수단을 갖추는 것을 의미합니다.

예를 들어, 한 계좌에서 다른 [5]계좌로 금액을 이체하는 개념적으로 매우 간단한 방법을 사용하는 은행 애플리케이션을 고려해보자.

무효 갈아타다(계좌 ACC에서, 계좌 액세스, 인트 ) 던지다 예외. {   한다면 (ACC에서.get Balance() < > )       던지다 신규 불충분한 Funds Exception();    ACC에서.철수하다();   액세스.보증금(); } 

단, 이 전송 방식에서는 전개된 어플리케이션에 필요한 몇 가지 고려사항이 간과됩니다.즉, 현재 사용자가 이 조작을 실행할 권한이 있는지 확인하기 위한 보안 체크가 결여되어 있습니다.데이터베이스 트랜잭션은 우발적인 데이터 손실을 방지하기 위해 조작을 캡슐화해야 합니다.진단에서는 조작을 다음과 같이 해야 합니다.시스템 로그에 기록되는 등

예를 들어, 이러한 모든 새로운 문제가 포함된 버전은 다음과 같습니다.

무효 갈아타다(계좌 ACC에서, 계좌 액세스, 인트 , 사용자 유저,     로거 로거, 데이터베이스 데이터베이스) 던지다 예외. {   로거.정보("이체....");      한다면 (!is User Authorized(사용자 인증 완료)(유저, ACC에서)) {     로거.정보("사용자에게 권한이 없습니다.");     던지다 신규 Unauthorized User Exception(무허가 사용자 예외)();   }      한다면 (ACC에서.get Balance() < > ) {     로거.정보("자금 부족");     던지다 신규 불충분한 Funds Exception();   }    ACC에서.철수하다();   액세스.보증금();    데이터베이스.commit Changes(변경사항 커밋)();  // 아토믹 오퍼레이션.    로거.정보("거래 성공"); } 

이 예에서 다른 관심사는 기본 기능(비즈니스 로직 관심사라고도 함)과 얽혀 있습니다.트랜잭션, 보안 및 로깅은 모두 교차 우려 사항의 예입니다.

이제 애플리케이션 보안 고려사항을 갑자기 변경해야 할 경우(예를 들어) 어떻게 되는지 생각해 보십시오.이 프로그램의 현재 버전에서는 보안 관련 작업이 여러 가지 방법으로 분산되어 있으며 이러한 변경에는 상당한 노력이 필요합니다.

AOP는 프로그래머가 애스펙트라고 불리는 독립형 모듈에서 교차 우려를 표현할 수 있도록 함으로써 이 문제를 해결하려고 합니다.애스펙트에는 어드바이스(프로그램의 지정된 포인트에 결합된 코드) 및 유형선언(다른 클래스에 추가된 구조 부재)이 포함될 수 있습니다.예를 들어 보안 모듈은 은행 계좌에 액세스하기 전에 보안 검사를 수행하는 조언을 포함할 수 있습니다.포인트 컷은 은행 계좌에 접속할 수 있는 시간(접속 포인트)을 정의하고 조언 본문의 코드는 보안 검사를 실행하는 방법을 정의합니다.이렇게 하면 수표와 장소를 모두 한 곳에 유지할 수 있습니다.게다가 좋은 포인트 컷은 나중에 프로그램 변경을 예상할 수 있기 때문에, 다른 개발자가 은행 계좌에 액세스하기 위한 새로운 방법을 작성하면, 그 조언은 새로운 방법을 실행할 때 적용됩니다.

위의 예에서는 어떤 측면에서 로깅을 구현하고 있습니다.

측면 로거 {   무효 은행..갈아타다(계좌 ACC에서, 계좌 액세스, 인트 , 사용자 유저, 로거 로거)  {     로거.정보("이체....");   }    무효 은행..머니백 취득(사용자 유저, 인트 거래.아이디, 로거 로거)  {     로거.정보("사용자가 환불을 요청했습니다.");   }    // 기타 교차 코드. } 

AOP는 디버깅툴 또는 사용자 레벨의 툴이라고 생각할 수 있습니다.어드바이저는 기능을 변경할 수 없는 경우(사용자 레벨)[6] 또는 실가동 코드의 기능을 변경할 필요가 없는 경우(디버깅)를 위해 예약해야 합니다.

결합점 모델

애스펙트 지향 언어의 어드바이스 관련 컴포넌트는 Join Point Model(JPM; 조인 포인트모델)을 정의합니다.JPM은 다음 3가지를 정의합니다.

  1. 조언이 실행될 수 있을 때.실행 중인 프로그램에서 추가 동작을 유용하게 결합할 수 있는 점이기 때문에 이러한 점을 결합 지점이라고 합니다.결합점은 일반 프로그래머가 유용하게 사용하기 위해 주소 지정이 가능하고 이해할 수 있어야 합니다.또한 중요한 프로그램 변경 시에도 안정적이어야 하며, 이러한 변경 시에도 안정적이어야 합니다.많은 AOP 구현은 결합 포인트로 메서드 실행 및 필드 참조를 지원합니다.
  2. 포인트 이라고 하는 결합점을 지정(또는 정량화)하는 방법.포인트 컷은 지정된 결합점이 일치하는지 여부를 결정합니다.대부분의 유용한 포인트 컷 언어는 기본 언어와 같은 구문(예: AspectJ는 Java 시그니처를 사용)을 사용하며 이름 지정 및 조합을 통해 재사용할 수 있습니다.
  3. 결합점에서 실행할 코드를 지정하는 수단입니다.Aspect J는 이 조언을 호출하여 조인 포인트 전, 후 및 주변에서 실행할 수 있습니다.일부 구현에서는 다른 클래스의 한 측면에서 메서드를 정의하는 것과 같은 기능도 지원합니다.

결합점 모델은 노출된 결합점, 결합점 지정 방법, 결합점에서 허용되는 작업 및 표현 가능한 구조 개선을 기반으로 비교할 수 있습니다.

Aspect J의 결합점 모델

  • AspectJ의 결합 포인트에는 메서드 또는 컨스트럭터 호출 또는 실행, 클래스 또는 오브젝트 초기화, 필드 읽기 및 쓰기 액세스, 예외 핸들러 등이 포함됩니다.루프, 슈퍼콜, 슬로우구, 복수문 등은 포함되지 않습니다.
  • 포인트 컷은 기본 포인트지정자(PCD)의 조합으로 지정됩니다.

    "Kinded" PCD는 특정 종류의 조인 포인트(예를 들어 메서드 실행)와 일치하며 Java와 유사한 서명을 입력으로 받아들이는 경향이 있습니다.이러한 포인트 컷 중 하나는 다음과 같습니다.

    execution set*(*)

    메서드 이름이 "로 시작하는 경우 이 포인트 컷은 메서드 실행 결합점과 일치합니다.set어떤 타입이든 정확히 하나의 인수가 있습니다.

    "Dynamic" PCD는 런타임 유형과 바인드 변수를 확인합니다.예를들면,

    이(포인트)

    이 포인트 컷은 현재 실행 중인 개체가 클래스의 인스턴스일 때 일치합니다.Point. Java의 일반 유형 조회를 통해 클래스 이름 미수식을 사용할 수 있습니다.

    "Scope" PCD는 결합 지점의 어휘 범위를 제한합니다.예를 들어 다음과 같습니다.

    (com.company) 내.*)

    이 포인트 컷은 모든 유형의 연결 지점과 일치합니다.com.company패키지.는, 1 개의 시그니처와 많은 것을 일치시키기 위해서 사용할 수 있는 와일드 카드의 1 형식입니다.

    포인트 컷을 구성하고 재사용할 수 있도록 이름을 지정할 수 있습니다.예를 들어 다음과 같습니다.

     포인트 컷 세트() : 실행(* 세트*(*) ) & & 이것.(포인트) & & 이내에(com.회사.*); 
    메서드 이름이 "로 시작하는 경우 이 포인트 컷은 메서드 실행 결합점과 일치합니다.set" 및this유형의 인스턴스입니다.Point에서com.company패키지."라는 이름을 사용하여 참조할 수 있습니다.set()".
  • 어드바이스는 연결점(포인트컷으로 지정)에서 특정 코드(메서드에서 유사한 코드 지정)를 실행하도록 지정합니다.포인트 컷이 결합점과 일치하면 AAP 런타임에서 자동으로 조언이 호출됩니다.예를 들어 다음과 같습니다.
     끝나고() : 세트() {    표시.갱신하다();  } 
    이는 효과적으로 다음과 같이 지정됩니다. "포인트컷이 결합점과 일치할 경우 코드를 실행합니다.Display.update()연결 지점이 완료된 후"

기타 잠재적 결합점 모델

다른 종류의 JPM이 있습니다.모든 어드바이스 언어는 JPM으로 정의할 수 있습니다.예를 들어 UML의 가상 애스펙트 언어에는 다음과 같은 JPM이 있습니다.

  • 결합점은 모두 모델 요소입니다.
  • 포인트 컷은 모델 요소를 결합한 부울식입니다.
  • 이러한 점에서 영향을 미치는 방법은 일치하는 모든 결합점을 시각화하는 것입니다.

유형간 선언

유형 간 선언은 모듈 구조에 영향을 미치는 교차 우려 사항을 표현하는 방법을 제공합니다.오픈 클래스 및 확장 메서드라고도 불리는 이 메서드를 사용하면 프로그래머는 한 곳에서 다른 클래스의 멤버 또는 부모를 선언할 수 있습니다.일반적으로 관심사와 관련된 모든 코드를 한 측면에서 결합할 수 있습니다.예를 들어 프로그래머가 대신 방문자를 사용하여 교차 표시 업데이트 문제를 구현한 경우, 방문자 패턴을 사용한 유형 간 선언은 AspectJ에서 다음과 같이 보일 수 있습니다.

  측면 디스플레이 업데이트 {     무효 포인트.acceptVisitor(방문자 수락)(방문자 v) {       v.방문하다(이것.);     }     // 기타 교차 코드...   } 

이 코드 스니펫에 의해acceptVisitor에의 메서드Point학급.

AOP 구현이 항상 모든 클라이언트를 제어할 수 있는 경우를 제외하고 기존 클래스의 클라이언트가 계속 작동할 수 있도록 구조 추가가 원래 클래스와 호환되어야 합니다.

실행

AOP 프로그램은 기본 언어 및 환경에 따라 두 가지 방법으로 다른 프로그램에 영향을 미칠 수 있습니다.

  1. 원어로 유효하고 일반 프로그램과 최종 통역자를 구별할 수 없는 복합 프로그램이 생산된다.
  2. AOP 기능을 이해하고 구현하기 위해 궁극의 인터프리터 또는 환경이 업데이트됩니다.

환경변화의 어려움은 대부분의 구현이 직조라고 불리는 프로그램 변환을 통해 호환되는 조합 프로그램을 제작한다는 것을 의미합니다.애스펙트 위버는 애스펙트 지향 코드를 읽고 애스펙트가 통합된 적절한 오브젝트 지향 코드를 생성한다.동일한 AOP 언어는 다양한 위빙 방법을 통해 구현될 수 있으므로, 위빙 구현의 관점에서 언어의 의미를 이해해서는 안 됩니다.사용하는 조합 방법에 따라 영향을 받는 것은 구현 속도와 도입의 용이성뿐입니다.

시스템은 프로그램소스 파일에 액세스 할 필요가 있는 프리프로세서(원래 CFront에 C++가 실장되어 있던 것)를 사용해 소스 레벨의 위빙을 실장할 수 있습니다.그러나 Java의 잘 정의된 바이너리 형식을 통해 바이트 코드 위버는 .class-file 형식의 Java 프로그램과 함께 작업할 수 있습니다.바이트 코드 위버는 빌드 프로세스 중 또는 위브 모델이 클래스 단위인 경우 클래스 로드 중에 배치할 수 있습니다.Aspect J는 2001년에 소스 레벨의 위빙에서 시작하여 2002년에 클래스별 바이트 코드 위버를 제공했으며 2005년에 Aspect Werkz가 통합된 후 고급 로드 시간 지원을 제공했습니다.

런타임에 프로그램을 결합하는 솔루션은 프로그래머의 분리된 모델을 유지하기 위해 프로그램을 적절히 분리할 수 있는 뷰를 제공해야 합니다.여러 소스 파일에 대한 Java의 바이트 코드 지원을 통해 모든 디버거가 소스 편집기에서 적절하게 짜여진 .class 파일을 거치도록 합니다.그러나 일부 서드파티 디컴파일러는 지원되는 모든 바이트 코드 형식이 아닌 Javac에서 생성된 코드를 예상하기 때문에 직조된 코드를 처리할 수 없습니다(아래의 § 비판 참조).

도입 시간 짜기는 또 다른 [7]접근 방식을 제공합니다.이는 기본적으로 후처리를 의미하지만 생성된 코드를 패치하는 것이 아니라 기존 클래스를 하위 분류하여 메서드 오버라이딩에 의해 변경이 도입되도록 합니다.기존 클래스는 런타임에도 변경되지 않고 그대로 유지되며 개발 중에 모든 기존 도구(디버거, 프로파일러 등)를 사용할 수 있습니다.IBM의 WebSphere같은 많은 Java EE 애플리케이션 서버 구현에서도 유사한 접근 방식이 이미 입증되었습니다.

용어.

Aspect 지향 프로그래밍에서 사용되는 표준 용어는 다음과 같습니다.

교차 우려 사항
OO 모델의 대부분의 클래스는 단일 특정 기능을 수행하지만, 종종 다른 클래스와 공통의 2차 요건을 공유합니다.예를 들어 스레드가 메서드에 들어가거나 메서드에서 나올 때마다 데이터 액세스레이어 내의 클래스 및 UI 레이어 내의 클래스에 로깅을 추가할 수 있습니다.액세스[8] 제어나 정보 흐름 [9]제어 의 보안과 관련된 문제가 발생할 수 있습니다.각 클래스의 프라이머리 기능은 매우 다르지만, 세컨더리 기능을 실행하는 데 필요한 코드는 많은 경우 동일합니다.
조언
이것은 기존 모델에 적용하려는 추가 코드입니다.이 예에서는 스레드가 메서드에 들어가거나 메서드에서 나올 때마다 적용하는 로깅 코드입니다.
포인트 컷
이는 교차관계의 적용을 필요로 하는 출원의 실행시점에 부여되는 용어이다.이 예에서는 스레드가 메서드에 들어갈 때 포인트 컷에 도달하고 스레드가 메서드를 나갈 때 다른 포인트 컷에 도달합니다.
측면
포인트 컷과 어드바이스의 조합을 애스펙트라고 부릅니다.위의 예에서는 포인트 컷을 정의하고 올바른 조언을 제공함으로써 애플리케이션에 로깅 측면을 추가합니다.

다른 프로그래밍 패러다임과의 비교

객체 지향 프로그래밍계산적 반영에서 양상이 나타났다.AOP 언어는 메타 객체 프로토콜과 비슷하지만 더 제한적입니다.각 측면은 주제, 믹스 위임과 같은 프로그래밍 개념과 밀접하게 관련되어 있습니다.애스펙트 지향 프로그래밍 패러다임을 사용하는 다른 방법으로는 구성 필터와 하이퍼라이스 방식이 있습니다.적어도 1970년대부터 개발자들은 AOP를 위한 구현 방법 중 일부를 닮은 가로채기와 디스패치 패치의 형태를 사용해 왔지만, 이것들은 크로스 컷 사양이 [citation needed]한 곳에 기술하는 의미론을 가지고 있지 않았다.

설계자는 C#의 부분 타입과 같은 코드의 분리를 실현하기 위한 대체 방법을 고려했지만, 그러한 접근법에는 하나의 [citation needed]선언문으로 코드의 여러 결합점에 도달할 수 있는 정량화 메커니즘이 없다.

관련이 없는 것처럼 보일 수 있지만 테스트에서 mock 또는 stub을 사용하려면 조언 등의 AOP 기술을 사용해야 합니다.여기서 협업 물체는 테스트의 목적인 교차 절삭을 위한 것입니다.따라서 다양한 Mock Object 프레임워크는 이러한 기능을 제공합니다.예를 들어 프로세스가 서비스를 호출하여 잔액을 얻습니다.금액의 출처가 되는 공정의 테스트에서는 공정에서 요구 [citation needed]사항에 따라 잔액을 사용하는 것만이 중요합니다.

도입에 관한 문제

프로그래머는 [10]오류를 방지하기 위해 코드를 읽고 무슨 일이 일어나고 있는지 이해할 수 있어야 합니다.적절한 교육을 받더라도 프로그램의 [11]정적 구조와 동적 흐름을 시각화하는 적절한 지원이 없으면 교차 관심사를 이해하는 것이 어려울 수 있습니다.2002년부터 Aspect J는 교차 우려의 시각화를 지원하기 위해 IDE 플러그인을 제공하기 시작했습니다.이러한 기능, 애스펙트 코드 어시스트 리팩터링이 일반화되어 있습니다.

AOP의 위력을 감안할 때 프로그래머가 크로스컷을 논리적으로 잘못 표현하면 광범위한 프로그램 오류로 이어질 수 있습니다.반대로, 다른 프로그래머는 프로그램의 결합 지점을 변경할 수 있습니다. 예를 들어, 이름 변경이나 방법 이동 등을 통해 애스펙트 라이터가 예상하지 못한 방식으로 변경하며 예기치 않은 결과를 초래할 수 있습니다.교차 우려 사항을 모듈화하는 것의 장점 중 하나는 한 명의 프로그래머가 시스템 전체에 쉽게 영향을 미칠 수 있다는 것입니다. 그 결과, 특정 장애에 대한 두 명 이상의 개발자 간의 책임에 대한 충돌과 같은 문제가 발생합니다.단, 이러한 문제에 대한 해결책은 AOP가 있는 경우 훨씬 쉬워질 수 있습니다.이는 AOP가 없는 대응 문제는 훨씬 [citation needed]더 확산될 수 있기 때문입니다.

비판

AOP의 효과에 대한 가장 기본적인 비판은 제어 흐름이 모호하고, 많은 악의가 있는 GOTO보다 더 심각할 뿐만 아니라 실제로 농담 COM FROM 진술과 [11]매우 유사하다는 것입니다.AOP의 많은 정의의 기본인 애플리케이션(문제의 코드는 어드바이스를 적용할 것을 지시하지 않으며, 포인트 컷에 대신 명시되어 있음)의 망각은 명시적인 메서드 [11][12]호출과는 대조적으로 어드바이스가 보이지 않음을 의미한다.예를 들어 COME FROM 프로그램을 [11]비교합니다.

 5 입력 X 10 인쇄하다 '결과:' 15 인쇄하다 X 20 와라 부터 10 25      X = X * X 30 돌아가다 

유사한 의미론을 가진 AOP fragment를 사용합니다.

주된() {     입력 x     인쇄물(결과(x)) } 입력 결과(인트 x) { 돌아가다 x } 주위에(인트 x): 불러(결과(인트)) & & args(x) {     인트 임시직 = 진행하다(x)     돌아가다 임시직 * 임시직 } 

실제로, 포인트 컷은 런타임 조건에 의존할 수 있으며, 따라서 정적 결정론적이지 않습니다.이 문제는 완화될 수 있지만 정적 분석 및 IDE 지원으로 해결되지는 않습니다.

일반적인 비판은 AOP가 "모듈화와 코드 구조"를 개선하는 것을 전제로 한다는 것이지만, 일부에서는 오히려 이러한 목표를 저해하고 "프로그램의 독립적 개발과 이해 가능성"[13]을 저해한다고 반박한다.구체적으로, 포인트 컷에 의한 정량화는 모듈화를 깨뜨린다: "일반적으로, 사람은 측면 지향 [14]프로그램의 동적 실행에 대해 추론하기 위한 전체 프로그램 지식을 가져야 한다."또한, 그 목표(교차관계의 모듈화)는 잘 이해되고 있지만, 실제 정의는 명확하지 않고 확립된 다른 기술과 [13]명확하게 구별되지 않는다.교차 우려는 상호 교차될 수 있으며 [13]주문과 같은 해결 메커니즘이 필요합니다.사실, 측면은 거짓말쟁이 [15]역설과 같은 문제를 야기하면서 자신에게 적용될 수 있다.

기술적인 비판에는 포인트 컷의 정량화(어드바이저가 실행되는 장소의 정의)가 「프로그램의 변경에 지극히 민감하다」라고 하는 것이 포함됩니다.이것은 취약한 포인트 컷[13]문제로 알려져 있습니다.포인트 컷에 관한 문제는 다루기 어려운 것으로 간주됩니다.포인트 컷의 정량화를 명시적인 주석으로 대체하면 속성 지향 프로그래밍을 대신 얻을 수 있습니다.이것은 단순히 명시적인 서브루틴 호출이며,[13] AOP가 해결하도록 설계된 것과 동일한 산란 문제를 겪고 있습니다.

실장

다음 프로그래밍 언어는 언어 내 또는 외부 라이브러리로 AOP를 구현했습니다.

「 」를 참조해 주세요.

주 및 참고 자료

  1. ^ Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J. M.; Irwin, J. (1997). Aspect-oriented programming (PDF). ECOOP'97. Proceedings of the 11th European Conference on Object-Oriented Programming. LNCS. Vol. 1241. pp. 220–242. CiteSeerX 10.1.1.115.8660. doi:10.1007/BFb0053381. ISBN 3-540-63089-9. Archived (PDF) from the original on 12 January 2016.
  2. ^ "어댑티브 객체 지향 프로그래밍:전파 패턴을 사용한 디메터 접근법" Karl Liebherr 1996 ISBN 0-534-94602-X는 기본적으로 동일한 것을 잘 작동시킨 버전을 제시한다(Liebherr은 나중에 이를 인식하고 그의 접근방식을 재구성했다).
  3. ^ Don Box; Chris Sells (4 November 2002). Essential.NET: The common language runtime. Addison-Wesley Professional. p. 206. ISBN 978-0-201-73411-9. Retrieved 4 October 2011.
  4. ^ Roman, Ed; Sriganesh, Rima Patel; Brose, Gerald (1 January 2005). Mastering Enterprise JavaBeans. John Wiley and Sons. p. 285. ISBN 978-0-7645-8492-3. Retrieved 4 October 2011.
  5. ^ 주의: 이 문서의 예는 Java 언어와 유사한 구문으로 나타납니다.
  6. ^ "gnu.org". www.gnu.org. Archived from the original on 24 December 2017. Retrieved 5 May 2018.
  7. ^ "Archived copy" (PDF). Archived from the original (PDF) on 8 October 2005. Retrieved 19 June 2005.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  8. ^ B. 드윈, B.밴하우트와 B.데커."애스펙트 지향 프로그래밍을 통한 보안"네트워크분산 시스템 보안의 진보(2002).
  9. ^ T. 파스퀴어, J. 베이컨, B.Shand. "FlowR: 정보 흐름 제어를 위한 Aspect Oriented Programming in Ruby."제13회 모듈러성 국제회의의 ACM 절차(Aspect Oriented Software Development)(2014).
  10. ^ Edsger Dijkstra, 2006-10-12 Wayback Machine에서 아카이브된 구조화 프로그래밍관한 메모, 1-2페이지
  11. ^ a b c d Constantinides, Constantinos; Skotiniotis, Therapon; Störzer, Maximilian (September 2004). AOP Considered Harmful (PDF). European Interactive Workshop on Aspects in Software (EIWAS). Berlin, Germany. Archived (PDF) from the original on 23 March 2016. Retrieved 5 May 2018.
  12. ^ C2: Come From
  13. ^ a b c d e Steimann, F(2006년)."aspect-oriented 프로그래밍의 역설적 성공".ACMSIGPLAN Notices.41(10):481–497.CiteSeerX 10.1.1.457.2210. doi:10.1145/1167515.1167514.,(슬라이드는 승객 Machine,slides 2시에 승객을 머신에 2015-09-23 Archived 2016-03-04 Archived, 추상은 승객을 머신에 2015-09-24 Archived), 프리드리히 Steimann, 게리 T.Leavens, OOPSLA 2006
  14. ^ "More Modular Reasoning for Aspect-Oriented Programs". Archived from the original on 12 August 2015. Retrieved 11 August 2015.
  15. ^ "AOP and the Antinomy of the Liar" (PDF). fernuni-hagen.de. Archived (PDF) from the original on 9 August 2017. Retrieved 5 May 2018.
  16. ^ 다수: Wayback Machine, LOM에서 2016-03-15년 아카이브 완료.2008-08-27 Wayback 머신에서 NET 아카이브 완료 2008-08-27, Enterprise Library 3.0 정책 주입 애플리케이션 블록 2007-01-19 아카이브 완료 2007-01-19, AspectDNG 아카이브 완료 2004-09-29 Wayback 머신에서 아카이브 완료, Dynamic Proxy 아카이브 2015-12-05 Wayback 머신에서 아카이브 완료 2005-08 컴포지트*하인, 시저NET 2006-07-25 Wayback Machine, DotSpect (.)에서 아카이브 완료SPECT) 2006-03-31년 봄에 Wayback Machine, Spring에서 아카이브 완료.NET 2006-04-02 Wayback Machine (기능의 일부), WiccaPhx에서 아카이브 완료.Morph 아카이브 2006-12-07 Wayback 머신, SetPoint 아카이브 2008-10-07 Wayback 머신
  17. ^ "Welcome to as3-commons-bytecode". as3commons.org. Archived from the original on 3 October 2014. Retrieved 5 May 2018.
  18. ^ "Ada2012 Rationale" (PDF). adacore.com. Archived (PDF) from the original on 18 April 2016. Retrieved 5 May 2018.
  19. ^ "Function Hooks". autohotkey.com. Archived from the original on 17 January 2013. Retrieved 5 May 2018.
  20. ^ 몇 가지:AspectC++, FeatureC+, AspectC 2006-08-21 Wayback Machine, AspeCt 지향 C 2008-11-20 Wayback Machine, Aspicere
  21. ^ "Cobble". vub.ac.be. Retrieved 5 May 2018.[영구 데드링크]
  22. ^ "AspectCocoa". neu.edu. Archived from the original on 26 October 2007. Retrieved 5 May 2018.
  23. ^ "ColdSpring Framework: Welcome". 5 November 2005. Archived from the original on 5 November 2005. Retrieved 5 May 2018.{{cite web}}: CS1 maint: bot: 원래 URL 상태를 알 수 없습니다(링크).
  24. ^ "Closer Project: AspectL". Archived from the original on 23 February 2011. Retrieved 11 August 2015.
  25. ^ "infra - Frameworks Integrados para Delphi - Google Project Hosting". Archived from the original on 9 September 2015. Retrieved 11 August 2015.
  26. ^ "meaop - MeSDK: MeObjects, MeRTTI, MeAOP - Delphi AOP(Aspect Oriented Programming), MeRemote, MeService... - Google Project Hosting". Archived from the original on 10 September 2015. Retrieved 11 August 2015.
  27. ^ "Google Project Hosting". Archived from the original on 25 December 2014. Retrieved 11 August 2015.
  28. ^ "RemObjects Cirrus". codegear.com. Archived from the original on 23 January 2012. Retrieved 5 May 2018.
  29. ^ "Emacs Advice Functions". gnu.org. Archived from the original on 24 October 2011. Retrieved 5 May 2018.
  30. ^ 모나드는 프로그램 코드를 변경하지 않고 프로그램 유형을 변경함으로써 프로그램 의미를 변경할 수 있습니다.드 Meuter, 볼프강(1997년)."양극 개방상에 대한 이론적 근거로서 Monads".국제 워크숍 Aspect-Oriented 프로그래밍에 ECOOP에:25.CiteSeerX 10.1.1.25.8262.Tabareau, 니콜라스, 피게로아, 이스마엘, Tanter, 에리크(3월 2013년)."ATypedMonadic 연결 측면의".제12회 국제 회의 Aspect-oriented 소프트웨어 개발에 회보.Aosd '13:171–184. doi:10.1145/2451436.2451457.아이 에스비엔 9781450317665.S2CID 27256161.매개 변수 형식 클래스 추가 기능이 형식에 추가될:허용한다.Sulzmann, 마틴, 왕, 멩(2007년 3월)."형식 클래스와 함께Aspect-oriented 프로그래밍".6워크숍 Aspect-oriented 언어의 기초:65–74에 논문집. doi:10.1145/1233833.1233842.아이 에스비엔 978-1595936615.S2CID 3253858..
  31. ^ 기타 다수: CaesarJ Archived 2008-12-19 at the Wikiwix, Config*Archived 2005-08-21, Dynaop Archived 2007-07-24, JAC Archived 2004-06-19 at the Wayback Machine, Google Guice 2004-09 Archivede웨이백 머신, JAML 아카이브 2005-04-15, JBoss AOP 아카이브 2006-10-17, LogicAJ 아카이브 2006-05-04, 오브젝트아카이브 2005-08-31 아카이브 2005-01 Wayback 머신, PRODE-01-24 아카이브 2007-01Wayback Machine, Spring 프레임워크(기능의 일부), Seasar, The JMangler Project Archived 2005-10-28, InjectJ Archived 2005-04-05 at the Wayback Machine, GluonJ Archived 2007-02-06 at Wayback Machine, Steam1808 Archive 2007
  32. ^ 다수: 2008-07-04 Wayback 머신에서 권장 아카이브 완료, Ajaxpect Wayback 머신에서 아카이브 완료 2016-07-09, jQuery AOP 플러그인 Wayback 머신에서 아카이브 완료 2008-01-13, Aspects 2006-05-08 Wikiwix, Aspect에서 아카이브 완료JS는 2008-12-16을 Wayback 머신에서, Cerny.js는 2007-06-27을 Wayback 머신에서, Dojo Toolkit은 2006-02-21을 Wayback 머신에서, Humax Web Framework는 2008-12-09를 Wayback 머신에서, Joose는 2015-03을 Wayback 머신에서 아카이브했습니다.YUI 3(Y)실행) 2011-01-25 Wayback Machine에 보관
  33. ^ 카테고리(애스펙트코드 캡슐화 가능) 및 이벤트 구동 프로그래밍(이벤트 핸들러 전후정의를 가능)에 대한 빌트인 지원을 사용합니다.
  34. ^ "AspectLua". Archived from the original on 17 July 2015. Retrieved 11 August 2015.
  35. ^ "MAKAO, re(verse)-engineering build systems". Archived from the original on 24 July 2012. Retrieved 11 August 2015.
  36. ^ "McLab". Archived from the original on 24 September 2015. Retrieved 11 August 2015.
  37. ^ "AspectML - Aspect-oriented Functional Programming Language Research". Archived from the original on 5 December 2010. Retrieved 11 August 2015.
  38. ^ "nemerle/README.md at master · rsdn/nemerle". GitHub. Retrieved 22 March 2018.
  39. ^ Adam Kennedy. "Aspect - Aspect-Oriented Programming (AOP) for Perl - metacpan.org". Archived from the original on 31 August 2013. Retrieved 11 August 2015.
  40. ^ 몇 가지: PHP-AOP(AOP.io) 2014-08-18 Wikiwix, Go! AOP 프레임워크 2013-03-01 Wayback Machine, PHPaspect Archived 2016-08-22 Wayback Machine, Seasar.PHP 2005-12-26 Wayback Machine, PHP-AOP, Flow Archived 2018-01-04 Wayback Machine, AAP PECL Extension Archived 2017-04-11 Wayback Machine
  41. ^ "bigzaphod.org is coming soon". www.bigzaphod.org. Archived from the original on 20 April 2016. Retrieved 5 May 2018.
  42. ^ 가지: Wayback Machine에서 PEACK 아카이브 2005-04-09, Wayback Machine에서 Aspyct AOP 아카이브 2004-10-09, Wayback Machine에서 Logilab의 애스펙트 모듈 아카이브 2005-03-09, Wayback Machine에서 Phius 아카이브 2005-04-08-082011-08-25 Wayback Machine 아카이브, aspectlib Wayback Machine 2014-11-05 아카이브
  43. ^ "PLaneT Package Repository : PLaneT > dutchyn > aspectscheme.plt". Archived from the original on 5 September 2015. Retrieved 11 August 2015.
  44. ^ "AspectR - Simple aspect-oriented programming in Ruby". Archived from the original on 12 August 2015. Retrieved 11 August 2015.
  45. ^ Dean Wampler. "Home". Archived from the original on 26 October 2007. Retrieved 11 August 2015.
  46. ^ "gcao/aspector". GitHub. Archived from the original on 4 January 2015. Retrieved 11 August 2015.
  47. ^ "AspectS". tu-ilmenau.de. Archived from the original on 6 January 2006. Retrieved 5 May 2018.
  48. ^ "MetaclassTalk: Reflection and Meta-Programming in Smalltalk". Archived from the original on 29 July 2015. Retrieved 11 August 2015.
  49. ^ "WEAVR". iit.edu. Archived from the original on 12 December 2008. Retrieved 5 May 2018.
  50. ^ "aspectxml - An Aspect-Oriented XML Weaving Engine (AXLE) - Google Project Hosting". Archived from the original on 12 September 2015. Retrieved 11 August 2015.

추가 정보

외부 링크