Aspect Oriented Programming
Download as PPTX, PDF•1 like•732 views
The document discusses Aspect Oriented Programming (AOP) as a solution to issues with Object Oriented Programming (OOP). AOP allows developers to dynamically modify static OOP models to address changing requirements over time. It does this by allowing cross-cutting concerns to be isolated as aspects that can be applied to classes without modifying the original class code. Aspects define pointcuts that specify where advice code should be inserted. This keeps core classes focused on their main purpose while modularizing common secondary functionality like logging across classes.
Aspect Oriented Programming
- 2. The only problem with Object Oriented programming is that it is essentially static, and a change in requirements can have a profound impact on development timelines. Solution? Aspect Oriented Programming
- 3. • Aspect-Oriented Programming (AOP) complements OO programming : by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops. • AOP allows us to dynamically modify our static model: by including the code required to fulfill the secondary requirements without having to modify the original static model . • Aspect-Oriented programming allows us the ability to apply aspects that alter behaviour to classes or objects independent of any inheritance hierarchy. We can then apply these aspects either during runtime or compile time • Allow us to do a better job of maintaining systems as they evolve.
- 4. 1. Cross-cutting concerns: Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though the primary functionality of each class is very different, the code needed to perform the secondary functionality is often identical. 2. Advice: This is the additional code that you want to apply to your existing model. In our example, this is the logging code that we want to apply whenever the thread enters or exits a method. 3. Join Point Well defined points in code that can be identified.Eg: when code invokes a method, that point at which that invocation occurs is considered the joinpoint. 4. Point-cut: This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied. A Point cut also contains an advice that is to occur when the join-point is reached. 5. Aspect: The combination of the point-cut and the advice is termed an aspect. In the example below, we add a logging aspect to our application by defining a point-cut and giving the correct advice. 6. Weaving: Combines advices with point cuts
- 5. • The type of logging required in our example is a cross- cutting concern. • It cannot be isolated or encapsulated in one or two specific classes; the logging involves changes in many places across the system. Our desire is to keep the system maintainable, and therefore we want our logging approach to keep the code as clean and simple as possible. • We would also like to avoid significant structural changes to the system's architecture. So how do we implement a cross-cutting concern such as logging? We could refactor all of the code by creating a logging class and performing the appropriate insertions. PROBLEMS? However, in a large system, this would be a time-consuming, error- prone job.
- 7. Late adaptations in response to environment changes : • Environment changes:– policy/organizational changes • access control, security, privacy • recurring deployment-like adaptations • service/usage-specific:- principal initiating a service call, time and context of a service call • asynchronous environment changes: location, level of service, usage of system resources
- 9. “AOP is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns”
- 10. • AOP is designed to handle cross-cutting concerns by providing a mechanism, named ASPECT, for expressing these concerns and automatically incorporating them into a system. • AOP does not replace existing programming paradigms and languages, instead, it works with them to improve their expressiveness and utility. • • It enhances our ability to express the separation of concerns necessary for a well-designed, maintainable software system. Some concerns are appropriately expressed as encapsulated objects, or components. Others are best expressed as cross-cutting concerns.
- 11. Image by Mark Rohde AOP
- 12. AspectJ is perhaps the best known and most widely used AOP implementation. The Finance system has an interface and several methods for updating an employee's financial data. The names of the methods all begin with the word update (e.g.,updateFederalTaxInfo), and each financial update takes an Employee object as an argument. Employees' personnel information is also updated through an Employee object
- 13. We can describe, in prose, what we need to do. Every time we call any of the updating functions and the update succeeds, we write a logging message. For simplicity, we will say that we print a logging message to the standard output. In the real system we would write to a log file. We would take three steps to implement our solution in AspectJ : 1. Identify places in the code where we want to insert the logging code. This is called defining join points in AspectJ. 2. Write the logging code. 3. Compile the new code and integrate it into the system.
- 14. • Centralize concerns implementation • Intercept method calls • Inject new behaviour • More reusable code • Cleaner code
- 15. What’s in it for YOU?
- 16. Write less code Read less code More concise and easy to understand More maintainable FEWER DEFECTS! Fewer code More interesting work Increased attention More PRODUCTIVITY!
- 17. AOP is complementary to OOP AOP targets a specific problem Code modularization OOP – Real world objects AOP – Functionalities
- 18. You can do AOP via: Dynamic Proxies Functional Programming Code Generation Dynamic Languages Static Weaving
- 19. Requires modification to every function No support for matching rules Manual aspect composition
- 20. • We will need to modify our process to accommodate AOP • Quality issues may be the biggest deterrents to adopting AOSD methods. • Tools will play a major part in industry adoption of AOP. In addition to compilers and editors, we need tools to help us reason about systems, identify potential cross-cutting concerns, and help us test in the presence of aspects. • Poor tool chain support - debuggers, profilers etc may not know about the AOP and so may work on code as if all the aspects had been replaced by procedural code. • Code bloat - small source can lead to much larger object code as code is "weaved" throughout the code base.
Editor's Notes
- #8: Which finally brings us to aspect oriented programming, and I’ll give you a second to read this quick definition from Wikipedia.
- #9: Which finally brings us to aspect oriented programming, and I’ll give you a second to read this quick definition from Wikipedia.
- #16: That’s all very nice, but why should you care about writing reusable and clean code? What do you get out of it?
- #17: Well, for one, you end up writing less code, and therefore you will need to read less code too. The code that you end up reading will be more concise and easy to understand as they’re no longer convoluted by cross-cutting concerns. As you reduce the complexity of your code, it becomes more maintainable too.
- #18: AOP and OOP are not mutually exclusive; AOP is in fact complimentary to OOP and help you become a better OOP developer by helping you enforce some important design principles of OOP. Unlike OOP, functional programming or declarative programming, which are general purpose paradigms aimed to solve most of the programming problems we face, and all competing to be the core paradigm of a language. AOP on the other hand, is a paradigm which attempts to solve one very specific problem. AOP and OOP both encourage code modularization and encapsulation, which leads to better code reusability and maintainability. The difference between the two paradigms come in the form of WHAT they modularize on: - OOP modularizes on basis of real world entities AOP modularizes on basis of functionalities
- #19: So hopefully that’s sufficient evidence for you to want to give AOP a go, but in terms of actually start doing some aspect-oriented programming you have quite a number of different options, including: Dynamic proxies with IoC frameworks - Functional programming using higher-order functions - Code generation using tools like T4 - Dynamic languages using their meta-programming capabilities - Static weaving, by modifying the MSIL in a post-compilation process
- #20: But, as I have demonstrated with recursive function, if you want to use the memoized version of the function f everywhere in your code, you’ll need to modify all the places where f is being used. Also, there’s no support for matching rules that lets you apply the same aspect to multiple functions in bulk. And when you want compose different aspects together, i.e. combining multiple higher-order functions, you’ll need to do it manually which is a task that’s easier said than done.