AOP 개념정리 시리즈 #1
Obliviousness는 Quantification과 함께 AOP의 두 축을 이루는 개념 입니다. OOP에 다형성(polymorphism), 정보은닉(information hiding), 캡슐화(encapsulation)가 있다면 AOP에는 Obilviousness와 Quantification이 있습니다.
객체 지향 프로그래밍의 다형성(polymorphism)은 "무엇"과 "어떻게"를 분리합니다. 즉 객체의 오퍼레이션(operation)을 호출했을 때(무엇) 그게 정확히 어떤 메서드를 호출하게 될지, 즉 어떻게 작동할 것인지(how)를 숨길 수 있게 합니다. AOP의 obliviousness는 "어떻게"와"어디"를 분리합니다. 즉 특정 코드(advice)가 언제(when) 호출되는지를 구체적으로 명시하지 않을 수 있습니다.
여기에서 중요한 점은 다형성과 obliviousness가 직교적이라는 사실입니다. "무엇"과 "어떻게"가 분리되었는지 여부와 무관하게 "어떻게"와 "어디"가 분리될 수 있습니다. 이는 AOP가 객체 지향 프로그래밍 패러다임에 국한되지 않음을 의미합니다.
다음은 Aspect Oriented Software Development에서 인용한 글입니다:
Obliviousness는 Quantification과 함께 AOP의 두 축을 이루는 개념 입니다. OOP에 다형성(polymorphism), 정보은닉(information hiding), 캡슐화(encapsulation)가 있다면 AOP에는 Obilviousness와 Quantification이 있습니다.
객체 지향 프로그래밍의 다형성(polymorphism)은 "무엇"과 "어떻게"를 분리합니다. 즉 객체의 오퍼레이션(operation)을 호출했을 때(무엇) 그게 정확히 어떤 메서드를 호출하게 될지, 즉 어떻게 작동할 것인지(how)를 숨길 수 있게 합니다. AOP의 obliviousness는 "어떻게"와"어디"를 분리합니다. 즉 특정 코드(advice)가 언제(when) 호출되는지를 구체적으로 명시하지 않을 수 있습니다.
여기에서 중요한 점은 다형성과 obliviousness가 직교적이라는 사실입니다. "무엇"과 "어떻게"가 분리되었는지 여부와 무관하게 "어떻게"와 "어디"가 분리될 수 있습니다. 이는 AOP가 객체 지향 프로그래밍 패러다임에 국한되지 않음을 의미합니다.
다음은 Aspect Oriented Software Development에서 인용한 글입니다:
Obliviousness states that one can't tell that the aspect code will execute by examining the body of the base code. Obliviousness is desirable because it allows greater Separation of Concerns in the system creation process.
(...omitted...)
This is not to ignore the disadvantages of obliviousness - that systems melded from separate minds may not function the way anyone intended and that systems composed by formal rules may produce surprising behavior. Nor is it the assertion that AOP techniques must always be used obliviously - there's no great harm in knowing what's going on, either. The argument is that one of the two things that distinguish Aspect Oriented Programming languages from their predecessors is the ability to oblivious.
--p24
RSS