Are aspects really needed for aspect-oriented programming?

Опубликовано 6 сентября 2016, 5:32

In this talk I will argue that we don't need the aspect as a separate abstraction mechanism for aspect-oriented program design, and there are good reasons to believe we might be better off without it. Rather, classes and aspects can be unified in a richer notion of class (the classpect). This unification does not significantly compromise the expressiveness of AspectJ-like languages. It improves the conceptual integrity of the programming model. And it improves the compositionality of components under aspect-oriented advising. To support these claims, I will present Eos: an AspectJ-like language based on C# that supports the extended class as the basic unit of modularity. I will show that Eos enables a better separation of integration and higher-order crosscutting concerns, and that it frees the designer from an overly constraining commitment to a conceptual model and architectural style based on separate class and aspect constructs. The technical underpinnings of Eos include support for aspect instantiation under program control, instance-level advising, advising as a generalized alternative to implicit invocation and overriding, and provision of a separate join-point-method binding construct. Time permitting I will address a second difficulty with current aspect-oriented design: it's reliance on the idea of obliviousness as a design strategy and criterion. I will present a solution based on a concept of crosscutting interfaces called join point interfaces(JPI's). JPI's constrain the design of code to be advised while documenting the assumptions that advising modules can make about such code. JPI's effectively separate two concerns that are too tightly coupled in current aspect-oriented design: the implementation of base (advised) and aspect (advising) code. Unlike other proposed approaches, the JPI approach entails no prior constraint on the exposure of join points, and it works independently of the details of the underlying join point model. The Eos language model and the JPI design rule approach together appear to provide a principled new basis for designing software with quantified advising as a composition mechanism, with improved modularity in design as a technical and economic objective. Acknowledgements: The first part of this talk (classpects) is based on the Ph.D. work of my student, Hridesh Rajan. The second part (obliviousness) is joint with Bill Griswold of the University of California, San Diego, and our students.This work has been supported by the National Science Foundation.