Aspect 지향 프로그래밍 이외의 교차 절단 문제에 대한 대안은 무엇입니까? [닫은]

Aspect 지향 프로그래밍은 교차 절단 문제를 다룰 것을 약속하지만 아직 완전히 팔리지는 않았습니다. 이 문제를 해결하려는 다른 시도가 있었습니까?

가능한 경우 교차 절단 문제를 별도의 모듈로 캡슐화 한 다음 종속성 주입을 통해 앱 전체에서 사용합니다. 이를 통해 코드 전체에서 사용되는 교차 절단 문제 구현을 다소 분리 할 수 ​​있습니다.

그러나 이것이 항상 우아하게 작동하는 것은 아닙니다. 이것이 사람들이 AOP와 같은 문제를 해결하려고 시도하는 이유입니다.

아직 보지 못한 두 가지 다른 옵션 :

모나드 및 화살표를 사용한 기능적 프로그래밍

FP에서는 함수 호출에 전달할 수있는 것과 같은 다른 것들과의 교차 관심사를 나타냅니다. 명시 적으로 지루해지기 때문에 Monads (또는 Arrows)를 사용하여 전달되는 추가 정보를 숨길 수 있습니다.

가장 일반적인 AOP 예는 로깅입니다. Monads를 사용하면 메시지 목록을 유지하는 "로거"모나드를 작성할 수 있습니다. LoggerMonad를 통해 수행하는 모든 기능에는 로그 메시지를 게시 할 수 있습니다. Arrows를 사용하면 응용 프로그램의 전체 데이터 흐름을 모델링하고 적절한 경우 모델에 로깅 루틴을 수행합니다. 내 생각에 화살표는 꽤 복잡합니다.

엔터티 / 컴포넌트 기반 프로그래밍

내가 게임 엔진을 위해 연구하고 실험 한 것. OOP에서와 같이 "개체"대신 모든 유형의 데이터 (구성 요소)와 서비스를 서비스 유형으로 분해합니다. 구성 요소는 관계형 데이터베이스에서와 같이 공통 ID로 그룹화되며 링크 된 구성 요소 그룹은 엔티티입니다. 이러한 시스템에 로깅을 추가하려면 시스템에 전달 된 구성 요소를 기반으로 트리거를 새로운 로깅 서비스에 추가합니다.

두 방법 모두 매우 쉽게 교차 절단 변경 작업을 수행 할 수 있지만 두 가지 방법 모두 고급 아키텍처 모델입니다. 따라서 처음부터 사용해야 할 것입니다. 구성 요소 모델은 이론적으로 기존 OOP 시스템으로 작업 할 수 있습니다. 귀하의 언어가 충분히 강력하다면 모나드도 가능할 것 같습니다.

교차 절단 문제를 해결하는 방법에는 여러 가지가 있습니다.

• 더 나은 디자인 패턴, 숙어 또는 추상화 메커니즘 사용 : 코드를 모듈화 할 수 있어도 코드가 크로스 커팅 될 수 있습니다. 코드를 유지하려면 코드화 할 수있는 디자인 기술을 사용하도록 리팩터링해야합니다. 이러한 리팩토링은 다른 종류의 크로스 컷팅을 야기 할 수 있지만, 크로스 컷이 안정적이고 변경되지 않는 것을 희망합니다.

• 보다 풍부한 언어 기능 개발 : 더 나은 추상화 메커니즘을 통해 많은 크로스 커팅 표현을 해결할 수 있으며 때로는 새로운 언어 기능이 필요합니다. 예를 들어, 기능 및 객체 지향 기능을 포함하는 고급 언어는 필요하지 않기 때문에 많은 디자인 패턴을 사용하지 않는 경우가 많습니다. 주의 자체가 자연에서 크로스 커팅 할 수 있습니다 디자인 패턴을 그들은 여러 가지 다른 객체와 클래스의 역할을 설명하기 때문에. Java에서는 런타임 비용이 높지만 측면 대신 리플렉션을 사용할 수 있습니다. 예를 들어 리플렉션을 사용하면 몇 줄의 코드만으로 수백 개의 클래스를 통해 방문자 패턴을 지원할 수 있습니다. DJ 라이브러리Northeastern에서 그 일을하는 하나의 반사 솔루션입니다. 믹스 인 은 C ++ (Java는 아님)에서 사용할 수있는 강력한 기술이며, 측면과 동일한 사용 사례를 제공 할 수 있습니다.

• 더 나은 도구 지원 제공 : grep리팩토링 작업 사용 및 수행과 같은 기술 은 크로스 컷팅 코드와 관련된 문제를 처리 할 수 ​​있습니다. 예를 들어, 인터페이스에 선언 된 메소드의 이름은 프로그램 전체를 잘라낼 수 있습니다. (기술적 인 차이점은 여기에 있습니다 : 이것은 메소드의 구현이 아니라 메소드의 이름이며, 크로스 컷입니다.) 이것은 일반적으로 "리팩토링 이름 바꾸기"를 사용하여 모든 것을 변경하는 Eclipse와 같은 IDE에서는 문제가되지 않습니다. 코드에서 이름을 사용하는 장소 이런 식으로 프로그래밍 환경이 충분히 표현할 때 언어 기능이 필요하지 않을 수 있습니다.

• 도메인 별 언어 사용 : AspectJ 이전의 초기 언어는 도메인별로 다르며 함수 구성을 효율적으로 결합하기위한 스레드 동기화 또는 데이터 흐름 분석과 같은 특정 문제에만 적용되었습니다. 이 언어는 실험적이지만 크로스 커팅과 관련된 우려 사항을 모듈화하는 데 큰 성공을 거두었습니다.

• Generative Programming Techniques 사용 : 메타 레벨까지 올라가는 것은 Aspect 지향 프로그래밍을위한 구현 기법으로 간주 될 수 있지만, 단순한 Aspect를 초월 할만큼 큰 영역입니다. 프로그램이 다른 프로그램의 소스 코드를 생성하는 생성 기술도 도메인 별 언어와 관련이 있습니다.

이 모든 것들에 대해 AOP를 공부하는 것이 적절하다고 생각합니다. AOP 언어를 사용하지 않더라도 AOP를 사용하면 코드 개념을 확장 할 수 있습니다.

일반적으로 선언적 기능, 특히 C # /. NET / Mono 세계의 특성 시스템으로 코드 요소에 태그를 지정합니다 .

나는 AOP에 대한 전문가는 아니지만 수년에 걸쳐 읽은 Lisp 에서 제공 하는 메타 프로그래밍 의 약한 형태 , 특히 메타 오브젝트 프로토콜과 같은 부분처럼 항상 보였습니다 .

그레고르 키잘 레스 (Gregor Kiczales)는 AMOP의 저자 중 하나였으며 나중에 AspectJ for Java를 썼다.