CSC/ECE 517 Fall 2010/ch3 3d AI: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 35: Line 35:


Lexical Introduction: Adding functionality to a class in place as opposed to extending it.
Lexical Introduction: Adding functionality to a class in place as opposed to extending it.
==Comparison of Aspect Oriented programming with Object Oriented Programming==
Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.




Line 74: Line 77:
  end
  end
  end
  end
==AspectJ==
An AspectJ aspect is a crosscutting type consisting of an advice on pointcuts and lexical introduction of behavior into other types. It is a general-purpose aspect-oritented extension to Java. Like Classes, aspects can have internal state and behavior, can extend other aspects and classes, and can implement interfaces. AspectJ uses extensions to the Java programming language to specify the crossing rules. These extensions are designed in such a way that a Java programmer would find no difference in using them. The AspectJ extensions use the following constructs to specify the weaving rules programmatically; they are the building blocks that form the modules that express the crosscutting concern’s implementation.
Join point
In AspectJ everything revolves around ajoin points, since they are the places where the crosscutting actions are woven in. Lets look at below code snippet:
public class Post{
...
void addPost(String text){
//add to Post database the given text
}
}
The join points in the Post Class include the execution of the addPost() method and the access to the database table Post.
Pointcut
A pointcut can select join point that is a call to a method, and it could also capture the method's context, such as the target object on which the method was called and the method's arguments.
We can write a pointcut that will capture the execution of the addPost() method in the Post class shown earlier:
execution(void Post.addPost(String))
The pointcut construct in AspectJ allows use of a few wildcards to capture related set of join points. For example,
the following pointcut captures the execution of all methods in Post class and its subclasses:
execution(void Post+*(..))





Revision as of 01:59, 7 October 2010

Introduction

Aspect Oriented Programming is a programming style which isolates the business logic of the program from its secondary or supporting functions. The basis of the aspect oriented programming is to add a third dimension to pre-existing dimensions of the Procedural Programming and Object Oriented Programming, by describing aspects that cross-cut the structure of the program.

Overview

If we look at the programming field from a distance we’ll generally divide programming languages into two main camps: procedural programming(POP) and object-oriented programming (OOP). Like all programming techniques these were invented as ways to structure programming to achieve conceptual separation of components. This separation is obtained by dividing programs into sub-structures of some kind so that we can think and program each one as a reasonably separate and autonomous entity.

When using POP we divide our program into separate functions or procedures and compose the program flow by redirecting it from one to another in what is essentially a linear structure. With OOP a second dimension is added as we structure our code into encapsulated units linked to each other. The control flow is now defined dynamically by the object structure and polymorphism. Aspect Oriented programming tries to add a third dimension to this structure by describing so called aspects that cross-cut the structure of the program.

Motivation and Terminologies

Traditional programming designs had poor modularity due to crosscutting dependencies. Especially in OOP each aspect is scattered by virtue of the function being spread over numerous unrelated functions or modules which maybe using its functionality, this means changing logging in one function requires modifying all the modules using this functionality, this works on the logic that the users knows/maintains a log of all the functions that use the functionality of the aspect Example.

Let us consider the example all know and love, Twitter. The model for which is shown in figure 1. If this model were to be implemented in an Object Oriented manner then the security aspect like authentication would have been scattered by virtue of a function called a logging, which is used by both the Users and Posts, a database transaction should encapsulate the operation in order to prevent accidental data loss Also, this operation should be logged onto the system log. We already see that authentication together with logging and transactions are now exhibiting cross-cutting concerns. Now consider the scenario in which the security specifications change , then in order to complete these changes this would require a major effort as the security-related operations are scattered across numerous methods.

Aspect Oriented Programming

Aspect Oriented Programming aims to solve this problem by including the concept called as aspects. Aspects are stand-alone modules used to express cross-cutting concerns. Figure demonstrates how our twitter module now looks with the inclusion of aspects. In Java, the aspects contain advice and intertype declarations.

In our example our authentication module can include a security check for the users before he/she can access the posts posted by himself and his/her friends. 

Key Concepts

Join Points: A well defined location at a point in the execution of a program.

PointCut: A set of join points

Advice: Code designed to run automatically at all join points in a particular pointcut. It can be marked as before, after or around i.e. in place of the join points in the pointcut.

Lexical Introduction: Adding functionality to a class in place as opposed to extending it.

Comparison of Aspect Oriented programming with Object Oriented Programming

Aspect oriented programming is not a complement to Object Oriented programming. It coexists together. AOP tries to lessen the limitations of traditional object oriented programming like cross-cutting in code, dependency in code change in repetitive methods which deal with aspects like logging, authentication and sessions.


AspectR

Aspects such loggin, security login, database session, transactions need to be done at the start of each method. If for example an application starts a session at the beginning of the application start and releases the resource only at the termination. A lot of resources are wasted and also may cause starvation of other applications. Hence we need frequent access to resources every time a needy method is called. Implementing this logic inside the method makes the aspect code repeated and cluttered all over the application source. To avoid this problem Aspect oriented programming can be adopted into the Ruby applications. Where all the aspect oriented functionality can be placed inside one behaviour. This behaviour can then be called before and after each method invocation. Thus making changes in aspect behaviour easy. Aspect oriented programming in Ruby can be implemented using Aquarium framework.

Creating a Simple Aspect in Ruby

Let us understand how easily an aspect behavior can be setup.

Setup

Install Aquarium gem from rubyForge website or alternatively use "gem install aquarium".

Example

Depending on the requirement of the application the aspect behavior may be changed from the one below. The snippet below shows the skeleton of a typical Aspect definition.

class Aspect_Name
include Aquarium::DSL
before :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc      
end
after :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Ending Session, loggin, transaction, security etc  
end
end


Before advice tells what work needs to be done before the method is called. After advice tells what work needs to be done after the method ends.

Another way of implementing is using Around Advice.

class Aspect_Name
include Aquarium::DSL
around :calls_to => :all_methods, :in_types => /Service$/ do |join_point, object, *args|
#Do Aspect Work Like Creating Session, loggin, transaction, security etc
result = join_point.proceed
#Do Aspect Work Like Ending Session, loggin, transaction, security etc
result  # block returns the result of the proceed.
end
end


References

1. http://en.wikipedia.org/wiki/Aspect-oriented_programming

2. http://www.objectmentor.com/resources/articles/AOP_in_Ruby.pdf

3. http://paginas.fe.up.pt/~ei01036/artigos/aop.pdf

4. http://www.cs.virginia.edu/~sullivan/

5. http://www.marvin-steinberg.de/alternative-implementations-for-aspect-oriented-programming-language-constructs-a-case-study-in-ruby/

6. http://www.theserverside.com/news/1364528/Implementing-Object-Caching-with-AOP

7. http://aspectr.sourceforge.net/

8. http://www.ironicwolf.com/2009/04/aspect-the-ruby-way/

9. http://rubyforge.org/frs/?group_id=4281