나는 AOP 분야의 초보자입니다. 처음으로 AOP의 개념을 적용한 코드를 작성했을 때, 애플리케이션에서 교차 절단 패턴을 제거하는 방법을 이해하게되어 기뻤습니다. 나는 보안, 로깅, 트랜잭션, 감사 및 기타 AOP 적용과 같은 교차 절단 패턴을 해결하려는 생각에 압도 당했다.
그러나 내가 처음으로 일하는 클라이언트에게 AOP 사용을 제안했을 때, 나는 그것을 지원하지 않는다고 들었다. 나는 AOP가 더 많은 유지 보수를 의미한다고 들었다. 코드가 변경되면 pointcuts를 변경해야합니다. 따라서 적용된 코드를 변경할 때마다 애스펙트를 분석, 변경 및 테스트해야 할 수도 있습니다.
이 문제에 관해 무엇을 말해야합니까? 왜 주류 회사들은 아직 AOP를 광범위하게 사용하지 못하고 있습니까? AOP 세상은 어디로 가고 있습니까?Aspect Oriented Programming의 미래
AOP는 비교적 새로운 개념이며 대기업은 일반적으로 새로운 개념을 염두에두고 있습니다. 그들은 많은 AOP 코드에 얽매이지 않고 유지할 수있는 사람들을 찾을 수 없다는 두려움을 가지고 있습니다.
구체적인 비판과 관련하여 그것은 알려지지 않거나 오해 된 것으로 보입니다. AOP의 요점은 교차 절단 문제 영역에서 코드 중복을 줄임으로써 유지 보수 작업을 줄이는 것입니다. 그러나 AOP를 사용하면 코드의 특정 부분을 볼 때 다른 곳에서 정의 된 부분이 동작을 완전히 바꿀 기회가 항상있을 수 있으므로 코드를 이해하기가 어려워 유지 관리가 더 어려워 질 수 있습니다.
개인적으로, AOP의 이점 (이 문제는 많은 부분을 고려해야할까요?)이이 문제를 능가하는지 잘 모르겠습니다. IDE에서 지원을 통해 문제를 해결할 수있는 유일한 방법은, 하지만 IDE에 훨씬 더 의존하게 만드는 것은 그렇게 큰 일도 아닙니다.
추세는 AOP (즉, 중앙 선언적 정의)와 비슷한 방식으로 거래 및 보안과 같은 중요하고 중요한 교차 관심사를 처리하지만 유지 보수 개발자를 혼란스럽게할만한 권한을 부여하지 않는 앱 서버 및 프레임 워크에 대한 것으로 보입니다 .
최근에 AOP에 대한 Google 비디오 프레젠테이션 (http://video.google.com/videoplay?docid=8566923311315412414)을 보았습니다. Gregor Kiczales는 기본적으로 AOP가 IDE 지원에 의존하고 있다고 말하면서 (이는 내가 어쨌든 이해했던 것임) 나는 이것이 용인 할 수 없다고 생각한다. –
아닙니다. TextPad를 사용하여 Spring에서 AOP를 수행 할 수 있습니다. 모든 구성입니다. IDE가 필요한 이유는 무엇입니까? – duffymo
@duffymo, 코드 유지 관리에 필요합니다. IDE는 어떤 부분의 코드를 정의했는지 보여줍니다. –
AOP는 실제로 잘 작동하지 않는 흥미로운 아이디어 중 하나입니다. Java는 AOP를 10 년 이상 사용할 수 있었고, 수정 된 것보다 더 많은 문제를 야기하기 때문에 많이 사용되지는 않았습니다.
그럼 AOP에 대한 실제 경험은 무엇입니까? 진술서를 사실과 함께 되돌릴 수 있습니까? 내 경험은 완전히 다릅니다. 일반적으로 AOP와 AspectJ는 지난 5 년 동안 내가 만난 가장 유용하고 우아하며 강력한 도구 중 하나이다. 그리고 저를 위해서 그것은 잘 작동합니다. :-) – kriegaex
응용 프로그램에서 성능 최적화를해야하고 AspectJ에 사용자 정의 프로파일 러를 작성하기로했습니다. 처음에는 AOP를 사용하는 것에 회의적 이었지만 그것이 작업을위한 완벽한 도구라는 것을 깨달았습니다.
그러나 내가 사용하지 않을 작업이 많이 있습니다. 응용 프로그램 기능에 영향을 줄 수있는 모든 항목에 사용하는 것에 대해서는 매우주의해야합니다. 간접 지정과 투명성 부족의 추가 계층은 기능을 추가하거나 버그를 수정하려는 개발자에게 너무 많은 문제를 일으킬 수 있습니다.
사람들은 Java 주석과 Guice 및 Spring과 같은 프레임 워크에서 이들의 사용이 AOP에서 영감을 얻었음을 잊어 버립니다. 나는 Java 주석이 AOP가 오늘 어디로 가고 있는지 말할 것이다.
나는 동의하지 않는다. 어노테이션이 메소드 본문에서 헤더까지 크로스 커팅 (cross-cutting) 문제를 이동시키기 때문에 주석이 소스 코드와 평균 * 산란 *의 일부이기 때문에 AOP가 제거 할 수있는 두 가지 효과가 있습니다. 가능하다면 aspectcut을 위해 특별히 도입 된 주석이 아닌 내 pointcuts가 유형 및 서명과 일치하도록하려고합니다. 다른 프레임 워크에서 사용하는 기존 주석이 있으면 괜찮습니다. 일치시키기 위해 사용하지만 AOP 전용 태그는 사용하지 않습니다. 이것이 어노테이션 기반 @AspectJ 구문 인 BTW에 일반 AspectJ 구문을 선호하는 이유이다. – kriegaex
우리는 AspectJ AOP 구현을 사용하며 매우 만족합니다. 당신은 당신의 툴킷의 또 다른 부분을 고려해야한다.이 툴킷은 '일반적인'자바에서 표현하기 쉬운 개념을 만든다. 우리는 현재 JMX 인터페이스를 우리의 서비스에 제공하기 위해 주로 이것을 사용합니다.
더 많은 IDE가 그것을 지원해야한다는 것은 사실입니다 (저는 여러분에게 JetBrains를보고 있습니다!), 채택을 확실히 도와 줄 것입니다.
나는 AOP가 더 많은 유지 보수를 의미한다고 들었다.
그건 바보이며 정확하게 잘못되었습니다. AOP는 코드에서 잡음을 제거하고 비즈니스 가치 제공에 집중할 수있게 해주는 필수 도구입니다. 비즈니스 규칙이 변경되면 코드의 새로운 변경 사항을 반영하기 위해 수천 마일의 프레임 워크 로직을 탐색 할 필요가 없습니다.
어떤 도구와 마찬가지로 올바르게 사용해야합니다. 내 AOP 로깅이 우발적으로 해독 된 신용 카드를 기록 할 것이라는 사실을 해결했다 :
http://www.agileatwork.com/what-happens-when-you-actually-use-aop-for-logging/
나는 당신이 실제로 꽤 차단되는 긴 이름을 태그에 대한이 질문을 만든 참조하십시오. 그렇게 분류학 자 배지를 얻지 않을 것입니다. –
@Ctrl Alt D-1337 당신이 무슨 말을하고 있는지 확실하지 않습니까? 나는 배지 수집을 위해 여기에 없다. – Jay
programmi? http://stackoverflow.com/questions/tagged/aspect-oriented-programmi –