Aspect-oriented programming: Introduction

Aspect-oriented programming: Introduction
http://portal.acm.org/citation.cfm?id=383853&coll=Portal&dl=GUIDE&CFID=18628671&CFTOKEN=48022287
 
OOP has difficulty

– localizing concerns involving global constraints and pandemic behaviors
– segregating concerns
– applying domain-specific knowledge
 
POP (Post-object programming) mechanism

– domain-specific languages
– generative programming
– generic programming
– constraint languages
– reflection and metaprogramming
– feature-oriented development
– view/viewpoints
– asynchronous message brokering
 
AOP(aspect-oriented programming)

– one important POP technology
– computer systems are better programmed by separately specifying the verious concerns of a system and some description of their relationships and then relying on mechanisms in the underlying AOP environment to weave or compose them together into a coherent program
– attempts to realize scattered converns as first-class elements and eject them horizontally from the object structure
– forcusd on mechanisms for simplifying the realization of cross-cutting converns
 
AOP vs. subprogram
 
subprogram: a concern whose code becomes tangled into other structural elements becomes a mess
AOP: aspect, weaving aspects and base code into coherent system
 
subprogram: require both knowledge and cooperation on the part of the programmers of the calling components
AOP: offer implicit invocation mechanisms for invoking behavior in code whose writer were unaware of the additional concerns
 
AOP goals
simpler system evolution, more comprehensible systems, adaptability, customizablity, and easier reuse
 
AOP issues
 
– clear-box approach
AOP can examine the program and aspect internals, producing a mixture of program and aspects
– black box approach
shroud components with aspect wrappers
 
– How an AOP system specifies aspects
– What composition mechanisms the system provides
– Implementation mechanisms
– Decoupling
– Software process
 
history of AOP
 
Karl Lieberherr (early researchers in the field)

The Law of Demeter: Objects shoud only have knowledge of closely releated objects
“Aspect-Oriented Programming with Adaptive Methods” the use of adaptive methods to avoid tangling by abstrating over the class structure
 
William Harrison and Harold Ossher

– separate specification of different class hierarchies, each implementing a concern with subsequent composition of appropriate hierarchies to build system varients (subject-oriented programming)
 
Peri Tarr

– allow multiple, simultaneous decompositions of the same software, extraction of concerns from existing software
– “Using Multidimensional Separation of Concerns to (Re)shape Evolving Software” by Ossher and Tarr
 
Mehmet Aksit and his group at Twente Univ.

– the earliest and most prominent proponents of filter-based approaches to AOP.
(In the late 1980s) filter principle was developed to express a generic data abstration mechanism)
– Bergmans and Aksit’s article “Composing Multiple Concerns Using Composition Filters”
how to embody aspects in explicit filters, by wrapping the filters around base components
 
AOP group at Xerox PARC
– the focus on crosscutting concerns is what distinguishes AOP from previous speration of concerns technologies
– developed a series of AO languages, culminating in AspectJ – “Getting Started With AspectJ”

Further Readings
 
the value of AOP technology
“Analyzing the Role of Aspects in Software Design”
“Does Aspect-Oriented Programming Work?”
 
discussions of the applications of AOP to systems development
“Structuring Operating System Aspects”
“A Layered Approach to Building Open Aspect-Oriented Systems”

the application of AOP to virtual design
“Handling Crosscutting Constraints in Domain-Specific Modeling”

an overview of using reflection techniques to implement aspects
“Aspect-Oriented Programming Using Reflection and Metaobject Protocols.”
 
Reference
 
Aspect-Oriented Software Development Web site
http://aosd.net/

“Aspect-oriented programming: Introduction”에 대한 7개의 생각

  1. AOP라는 일종의 Programming paradigm입니다. OOP가 해결하지 못하는 cross-cutting concern(쉽게 말해, 여러 모듈-함수, 클래스에 걸쳐 영향을 미치는 프로그래밍 문제)을 해결하는 방법을 추구한다고 보시면 되죠.

댓글 달기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.