AOP is the Programming technique that overcomes the problems faced by oop

1. PRESENTED BY:
Shreya Chattopadhyay

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

8. The SOLUTION…

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.