Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch7 7g mr

2010-12-11T03:58:32Z

Mwroda:

= Square-Rectangle Anti-Pattern =

The Square-Rectangle [http://en.wikipedia.org/wiki/Anti-pattern Anti-Pattern], also known as the [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse problem] is a software development problem that can occur in [http://en.wikipedia.org/wiki/Object_oriented_programming Object Oriented Programming] with inheritance when a base class contains methods which invalidate the derived class, and thereby violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle].

[[Image:Square-rectangle.gif|250px]]

== Description ==

Consider classes Rectangle and Square. By the 'is a' test, one might reasonably define the Square class as a specialization of the Rectangle class (Square is a Rectangle), where all sides are of equal length. But suppose Rectangle defines a constructor that takes two arguments, x and y, for the lengths of the sides. How can Square provide an implementation for this constructor? If the values passed for x and y are not the same, it would be unable to construct an instance of Square that satisfied the input criteria.

The situation is worse for modifier methods on the base class. Suppose Rectangle has a method setX which modifies only two sides of the rectangle. When called on a Square, it would cause the object to no longer be a square. This can be particularly problematic when new modifiers are added to an existing base class after it has been subclassed. If it has been subclassed improperly, the subclasses may be broken by the new functionality in the base class.

== Example ==

The following example illustrates the problem. In this case, Square has decided not to implement a constructor defined in Rectangle. But there is still a problem with the setX modifier:

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}

public void setX(int x) {
this.x = x;
}

public void setY(int y) {
this.y = y;
}

public void print() {
System.out.println(this.getClass().getName() + " has sides of length " + x + " and " + y);
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

public static void main(String[] args) {
Square s = new Square(10);
s.print();
s.setX(5);
s.print();
}
}

This produces the following output:

Square has sides of length 10 and 10
Square has sides of length 5 and 10

== Alternatives ==

=== Reverse the inheritance ===

Instead of having Square be a subclass of Rectangle, one could make Rectangle a subclass of Square. Afterall, you could say a Rectangle is a specialization of Square in which the sides don't need to be of the same length. Thus Square would define a constructor that takes only argument x. Rectangle could support that constructor and also provide another constructor which takes x and y. Likewise, Square could have only a setx method whereas Rectangle could also define a sety method.

public class Square
{
protected int x;

public Square(int x) {
this.x = x;
}

protected void setX(int x) {
this.x = x;
}
}

class Rectangle extends Square
{
protected int y;

public Rectangle() {}

public Rectangle(int x, int y) {
super(x);
this.y = y;
}

protected void setY(int y) {
this.y = y;
}
}

This is somewhat of a contrived example since Square does not have any additional information than Rectangle. Such may not be the case in more realistic scenarios.

=== Hidden constructor ===

The derived Rectangle class could choose to not provide an implementation for the constructor that takes arguments x and y. This would prevent any caller from instantiating an instance of Square with arguments x and y. This design maybe controversial since one normally expects a subclass to support all the constructors of the base class.

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

private Square(int x, int y) { }
}

=== Throw exception ===

The Square class could override any methods or constructors which violate the contract and throw an exception. In the constructor example above, it could throw an exception if the lengths provided for x and y are not equal. In the setx method example, it could check the value of y and throw an exception if the passed in value for x wasn't equal to y. This is somewhat dubious but does allow the setx method to be called if the value isn't changing.

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

private Square(int x, int y) {
throw new UnsupportedOperationException();
}
}

In Java the [http://download.oracle.com/javase/1.5.0/docs/api/java/lang/UnsupportedOperationException.html UnsupportedOperationException] could be thrown, which is a [http://download.oracle.com/javase/1.5.0/docs/api/java/lang/RuntimeException.html RuntimeException] and therefore does not need to be declared. If another type of exception was thrown, it would have to be declared.

=== Return new value ===

In this solution, the super class method would need to return its new value X when a method is called to change it.[1] The derived class reacts by stubbornly just returning its current value, thus forcing the caller to use a method supported for that class. This solution avoids throwing exceptions but could have undesireable consequences if the calling code is not careful to check the return value to make sure it was modified. But perhaps worse, it requires the method signatures to be changed in the base class to support the problem in the derived class.

class Rectangle
{
protected int x, y;

public Rectangle() {}

protected int setX(int x) {
this.x = x;
return this.x;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

protected int setX(int x) {
return this.x;
}
}

=== Make method more powerful ===

The implementation for the setx method in Square could just change the value of y also. This results in the method becoming more powerful, and might not be what the caller intended.

class Rectangle
{
protected int x, y;

public Rectangle() {}

protected void setX(int x) {
this.x = x;
}
}

public class Square extends Rectangle
{
public Square(int x) {
super(x, x);
}

protected void setX(int x) {
super(x);
this.y = x;
}
}

=== Return instance of new class ===

When a method is called that will mutate the object, the implementation could instantiate an instance of the base class and return that instead[1]. This requires the methods to declare a return type of the base class. This could have unexpected consequences on the program.

class Rectangle
{
protected int x, y;

public Rectangle() {}

protected Rectangle setX(int x) {
this.x = x;
return this;
}
}

public class Square extends Rectangle
{
public Square(int x) {
super(x, x);
}

protected Rectangle setX(int x) {
if (x == this.y)
return super(x);
else
return new Rectangle(x);
}
}

=== Use separate immutable and mutable classes ===

In this approach, the Rectangle class is [http://en.wikipedia.org/wiki/Immutable_object immutable] and therefore its methods cannot change derived instances, they can only return new instances of Rectangle. A separate MutableRectangle class could be defined and all the modifiers put into it.

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}

public void setX(int x) {
this.x = x;
}

public void setY(int y) {
this.y = y;
}
}

class ImmutableRectangle extends Rectangle
{
public Rectangle() { super(); }

public Rectangle(int x, int y) {
super(x, y);
}

private void setX(int x) { }

private void setY(int y) { }
}

public class Square extends ImmutableRectangle
{
...
}

As in some of the previous solutions, this has the disadvantage of requiring significant modifications to the design of the base class. It also requires the calling code to perform more assignments and may result in more memory being consumed by all the immutable instances around.

=== Initialize base class as mutable/immutable ===

This is similar to the above but not requiring separate mutable and immutable classes. Rectangle could be initialized, presumably by a constructor, with a state indicating if it can be modified. The modifier methods would check this state to see if the operation was allowed.

class Rectangle
{
protected int x, y;

protected boolean mutable;

public Rectangle(boolean mutable) {
this.mutable = mutable;
}

public void setX(int x) {
if (mutable)
this.x = x;
}
}

public class Square extends Rectangle
{
...
}

== See also ==

* [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse Problem] (Wikipedia)
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-Patterns] (Wikipedia)

== References ==

* [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse Problem] (Wikipedia)
* Robert C. Martin, [http://www.objectmentor.com/resources/articles/lsp.pdf The Liskov Substitution Principle], C++ Report, March 1996.
* Jean-Luc Hainaut, Jean-Marc Hick, Vincent Englebert, Jean Henrard, Didier Roland: Understanding Implementations of IS-A Relations. ER 1996: 42-57

CSC/ECE 517 Fall 2010/ch7 7g mr

2010-12-11T03:44:57Z

Mwroda:

= Square-Rectangle Anti-Pattern =

The Square-Rectangle [http://en.wikipedia.org/wiki/Anti-pattern Anti-Pattern], also known as the [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse problem] is a software development problem that can occur in [http://en.wikipedia.org/wiki/Object_oriented_programming Object Oriented Programming] with inheritance when a base class contains methods which invalidate the derived class, and thereby violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle].

[[Image:Square-rectangle.gif|right|150px]]

== Description ==

Consider classes Rectangle and Square. By the 'is a' test, one might reasonably define the Square class as a specialization of the Rectangle class (Square is a Rectangle), where all sides are of equal length. But suppose Rectangle defines a constructor that takes two arguments, x and y, for the lengths of the sides. How can Square provide an implementation for this constructor? If the values passed for x and y are not the same, it would be unable to construct an instance of Square that satisfied the input criteria.

The situation is worse for modifier methods on the base class. Suppose Rectangle has a method setX which modifies only two sides of the rectangle. When called on a Square, it would cause the object to no longer be a square. This can be particularly problematic when new modifiers are added to an existing base class after it has been subclassed. If it has been subclassed improperly, the subclasses may be broken by the new functionality in the base class.

== Example ==

The following example illustrates the problem. In this case, Square has decided not to implement a constructor defined in Rectangle. But there is still a problem with the setX modifier:

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}

public void setX(int x) {
this.x = x;
}

public void setY(int y) {
this.y = y;
}

public void print() {
System.out.println(this.getClass().getName() + " has sides of length " + x + " and " + y);
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

public static void main(String[] args) {
Square s = new Square(10);
s.print();
s.setX(5);
s.print();
}
}

This produces the following output:

Square has sides of length 10 and 10
Square has sides of length 5 and 10

== Alternatives ==

=== Reverse the inheritance ===

Instead of having Square be a subclass of Rectangle, one could make Rectangle a subclass of Square. Afterall, you could say a Rectangle is a specialization of Square in which the sides don't need to be of the same length. Thus Square would define a constructor that takes only argument x. Rectangle could support that constructor and also provide another constructor which takes x and y. Likewise, Square could have only a setx method whereas Rectangle could also define a sety method.

public class Square
{
protected int x;

public Square(int x) {
this.x = x;
}

protected void setX(int x) {
this.x = x;
}
}

class Rectangle extends Square
{
protected int y;

public Rectangle() {}

public Rectangle(int x, int y) {
super(x);
this.y = y;
}

protected void setY(int y) {
this.y = y;
}
}

This is somewhat of a contrived example since Square does not have any additional information than Rectangle. Such may not be the case in more realistic scenarios.

=== Hidden constructor ===

The derived Rectangle class could choose to not provide an implementation for the constructor that takes arguments x and y. This would prevent any caller from instantiating an instance of Square with arguments x and y. This design maybe controversial since one normally expects a subclass to support all the constructors of the base class.

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

private Square(int x, int y) { }
}

=== Throw exception ===

The Square class could override any methods or constructors which violate the contract and throw an exception. In the constructor example above, it could throw an exception if the lengths provided for x and y are not equal. In the setx method example, it could check the value of y and throw an exception if the passed in value for x wasn't equal to y. This is somewhat dubious but does allow the setx method to be called if the value isn't changing.

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

private Square(int x, int y) {
throw new UnsupportedOperationException();
}
}

In Java the [http://download.oracle.com/javase/1.5.0/docs/api/java/lang/UnsupportedOperationException.html UnsupportedOperationException] could be thrown, which is a [http://download.oracle.com/javase/1.5.0/docs/api/java/lang/RuntimeException.html RuntimeException] and therefore does not need to be declared. If another type of exception was thrown, it would have to be declared.

=== Return new value ===

In this solution, the super class method would need to return its new value X when a method is called to change it.[1] The derived class reacts by stubbornly just returning its current value, thus forcing the caller to use a method supported for that class. This solution avoids throwing exceptions but could have undesireable consequences if the calling code is not careful to check the return value to make sure it was modified. But perhaps worse, it requires the method signatures to be changed in the base class to support the problem in the derived class.

class Rectangle
{
protected int x, y;

public Rectangle() {}

protected int setX(int x) {
this.x = x;
return this.x;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

protected int setX(int x) {
return this.x;
}
}

=== Make method more powerful ===

The implementation for the setx method in Square could just change the value of y also. This results in the method becoming more powerful, and might not be what the caller intended.

class Rectangle
{
protected int x, y;

public Rectangle() {}

protected void setX(int x) {
this.x = x;
}
}

public class Square extends Rectangle
{
public Square(int x) {
super(x, x);
}

protected void setX(int x) {
super(x);
this.y = x;
}
}

=== Return instance of new class ===

When a method is called that will mutate the object, the implementation could instantiate an instance of the base class and return that instead[1]. This requires the methods to declare a return type of the base class. This could have unexpected consequences on the program.

class Rectangle
{
protected int x, y;

public Rectangle() {}

protected Rectangle setX(int x) {
this.x = x;
return this;
}
}

public class Square extends Rectangle
{
public Square(int x) {
super(x, x);
}

protected Rectangle setX(int x) {
if (x == this.y)
return super(x);
else
return new Rectangle(x);
}
}

=== Use separate immutable and mutable classes ===

In this approach, the Rectangle class is [http://en.wikipedia.org/wiki/Immutable_object immutable] and therefore its methods cannot change derived instances, they can only return new instances of Rectangle. A separate MutableRectangle class could be defined and all the modifiers put into it.

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}

public void setX(int x) {
this.x = x;
}

public void setY(int y) {
this.y = y;
}
}

class ImmutableRectangle extends Rectangle
{
public Rectangle() { super(); }

public Rectangle(int x, int y) {
super(x, y);
}

private void setX(int x) { }

private void setY(int y) { }
}

public class Square extends ImmutableRectangle
{
...
}

As in some of the previous solutions, this has the disadvantage of requiring significant modifications to the design of the base class. It also requires the calling code to perform more assignments and may result in more memory being consumed by all the immutable instances around.

=== Initialize base class as mutable/immutable ===

This is similar to the above but not requiring separate mutable and immutable classes. Rectangle could be initialized, presumably by a constructor, with a state indicating if it can be modified. The modifier methods would check this state to see if the operation was allowed.

class Rectangle
{
protected int x, y;

protected boolean mutable;

public Rectangle(boolean mutable) {
this.mutable = mutable;
}

public void setX(int x) {
if (mutable)
this.x = x;
}
}

public class Square extends Rectangle
{
...
}

== See also ==

* [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse Problem] (Wikipedia)
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-Patterns] (Wikipedia)

== References ==

* [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse Problem] (Wikipedia)
* Robert C. Martin, [http://www.objectmentor.com/resources/articles/lsp.pdf The Liskov Substitution Principle], C++ Report, March 1996.
* Jean-Luc Hainaut, Jean-Marc Hick, Vincent Englebert, Jean Henrard, Didier Roland: Understanding Implementations of IS-A Relations. ER 1996: 42-57

CSC/ECE 517 Fall 2010/ch7 7g mr

2010-12-11T03:32:25Z

Mwroda:

= Square-Rectangle Anti-Pattern =

The Square-Rectangle [http://en.wikipedia.org/wiki/Anti-pattern Anti-Pattern], also known as the [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse problem] is a software development problem that can occur in [http://en.wikipedia.org/wiki/Object_oriented_programming Object Oriented Programming] with inheritance when a base class contains methods which invalidate the derived class, and thereby violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle].

[[Image:Square-rectangle.gif|right|150px]]

== Description ==

Consider classes Rectangle and Square. By the 'is a' test, one might reasonably define the Square class as a specialization of the Rectangle class (Square is a Rectangle), where all sides are of equal length. But suppose Rectangle defines a constructor that takes two arguments, x and y, for the lengths of the sides. How can Square provide an implementation for this constructor? If the values passed for x and y are not the same, it would be unable to construct an instance of Square that satisfied the input criteria.

The situation is worse for modifier methods on the base class. Suppose Rectangle has a method setX which modifies only two sides of the rectangle. When called on a Square, it would cause the object to no longer be a square. This can be particularly problematic when new modifiers are added to an existing base class after it has been subclassed. If it has been subclassed improperly, the subclasses may be broken by the new functionality in the base class.

== Example ==

The following example illustrates the problem. In this case, Square has decided not to implement a constructor defined in Rectangle. But there is still a problem with the setX modifier:

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}

public void setX(int x) {
this.x = x;
}

public void setY(int y) {
this.y = y;
}

public void print() {
System.out.println(this.getClass().getName() + " has sides of length " + x + " and " + y);
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

public static void main(String[] args) {
Square s = new Square(10);
s.print();
s.setX(5);
s.print();
}
}

This produces the following output:

Square has sides of length 10 and 10
Square has sides of length 5 and 10

== Alternatives ==

=== Reverse the inheritance ===

Instead of having Square be a subclass of Rectangle, one could make Rectangle a subclass of Square. Afterall, you could say a Rectangle is a specialization of Square in which the sides don't need to be of the same length. Thus Square would define a constructor that takes only argument x. Rectangle could support that constructor and also provide another constructor which takes x and y. Likewise, Square could have only a setx method whereas Rectangle could also define a sety method.

public class Square
{
protected int x;

public Square(int x) {
this.x = x;
}

protected void setX(int x) {
this.x = x;
}
}

class Rectangle extends Square
{
protected int y;

public Rectangle() {}

public Rectangle(int x, int y) {
super(x);
this.y = y;
}

protected void setY(int y) {
this.y = y;
}
}

This is somewhat of a contrived example since Square does not have any additional information than Rectangle. Such may not be the case in more realistic scenarios.

=== Hidden constructor ===

The derived Rectangle class could choose to not provide an implementation for the constructor that takes arguments x and y. This would prevent any caller from instantiating an instance of Square with arguments x and y. This design maybe controversial since one normally expects a subclass to support all the constructors of the base class.

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

private Square(int x, int y) { }
}

=== Throw exception ===

The Square class could override any methods or constructors which violate the contract and throw an exception. In the constructor example above, it could throw an exception if the lengths provided for x and y are not equal. In the setx method example, it could check the value of y and throw an exception if the passed in value for x wasn't equal to y. This is somewhat dubious but does allow the setx method to be called if the value isn't changing.

class Rectangle
{
protected int x, y;

public Rectangle() {}

public Rectangle(int x, int y) {
this.x = x;
this.y = y;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

private Square(int x, int y) {
throw new UnsupportedOperationException();
}
}

In Java the [http://download.oracle.com/javase/1.5.0/docs/api/java/lang/UnsupportedOperationException.html UnsupportedOperationException] could be thrown, which is a [http://download.oracle.com/javase/1.5.0/docs/api/java/lang/RuntimeException.html RuntimeException] and therefore does not need to be declared. If another type of exception was thrown, it would have to be declared.

=== Return new value ===

In this solution, the super class method would need to return its new value X when a method is called to change it.[1] The derived class reacts by stubbornly just returning its current value, thus forcing the caller to use a method supported for that class. This solution avoids throwing exceptions but could have undesireable consequences if the calling code is not careful to check the return value to make sure it was modified. But perhaps worse, it requires the method signatures to be changed in the base class to support the problem in the derived class.

class Rectangle
{
protected int x, y;

public Rectangle() {}

protected int setX(int x) {
this.x = x;
return this.x;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

protected int setX(int x) {
return this.x;
}
}

=== Make method more powerful ===

The implementation for the setx method in Square could just change the value of y also. This results in the method becoming more powerful, and might not be what the caller intended.

class Rectangle
{
protected int x, y;

public Rectangle() {}

protected void setX(int x) {
this.x = x;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

protected void setX(int x) {
super(x);
this.y = x;
}
}

=== Return instance of new class ===

When a method is called that will mutate the object, the implementation could instantiate an instance of the base class and return that instead[1]. This requires the methods to declare a return type of the base class. This could have unexpected consequences on the program.

class Rectangle
{
protected int x, y;

public Rectangle() {}

protected Rectangle setX(int x) {
this.x = x;
return this;
}
}

public class Square extends Rectangle
{
public Square(int x) {
this.x = x;
this.y = x;
}

protected Rectangle setX(int x) {
if (x == this.y)
return super(x);
else
return new Rectangle(x);
}
}

=== Use separate immutable and mutable classes ===

In this approach, the Rectangle class is [http://en.wikipedia.org/wiki/Immutable_object immutable] and therefore its methods cannot change derived instances, they can only return new instances of Rectangle. A separate MutableRectangle class could be defined and all the modifiers put into it.

As in some of the previous solutions, this has the disadvantage of requiring significant modifications to the design of the base class. It also requires the calling code to perform more assignments and may result in more memory being consumed by all the immutable instances around.

=== Initialize base class as mutable/immutable ===

This is similar to the above but not requiring separate mutable and immutable classes. Rectangle could be initialized, presumably by a constructor, with a state indicating if it can be modified. The modifier methods would check this state to see if the operation was allowed.

== See also ==

* [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse Problem] (Wikipedia)
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-Patterns] (Wikipedia)

== References ==

* [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse Problem] (Wikipedia)
* Robert C. Martin, [http://www.objectmentor.com/resources/articles/lsp.pdf The Liskov Substitution Principle], C++ Report, March 1996.
* Jean-Luc Hainaut, Jean-Marc Hick, Vincent Englebert, Jean Henrard, Didier Roland: Understanding Implementations of IS-A Relations. ER 1996: 42-57

CSC/ECE 517 Fall 2010/ch7 7g mr

2010-12-01T15:35:32Z

Mwroda:

= Square-Rectangle Anti-Pattern =

The Square-Rectangle [http://en.wikipedia.org/wiki/Anti-pattern Anti-Pattern], also known as the [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse problem] is a software development problem that can occur in [http://en.wikipedia.org/wiki/Object_oriented_programming Object Oriented Programming] with inheritance when a base class contains methods which invalidate the derived class, and thereby violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle].

[[Image:Square-rectangle.gif|right|150px]]

== Description ==

Consider classes Rectangle and Square. By the 'is a' test, one might reasonably define the Square class as a specialization of the Rectangle class (Square is a Rectangle), where all sides are of equal length. But suppose Rectangle defines a constructor that takes two arguments, x and y, for the lengths of the sides. How can Square provide an implementation for this constructor? If the values passed for x and y are not the same, it would be unable to construct an instance of Square that satisfied the input criteria.

The situation is worse for modifier methods on the base class. Suppose Rectangle has a method setX which modifies only two sides of the rectangle. When called on a Square, it would cause the object to no longer be a square. This can be particularly problematic when new modifiers are added to an existing base class after it has been subclassed. If it has been subclassed improperly, the subclasses may be broken by the new functionality in the base class.

== Example ==

The following example illustrates the problem. In this case, Square has decided not to implement a constructor defined in Rectangle. But there is still a problem with the setX modifier:

class Rectangle
{
protected int x, y;

Rectangle() {}

Rectangle(int x, int y) {
this.x = x;
this.y = y;
}

void setX(int x) {
this.x = x;
}

void print() {
System.out.println(this.getClass().getName() + " has sides of length " + x + " and " + y);
}
}

public class Square extends Rectangle
{
Square(int x) {
this.x = x;
this.y = x;
}

public static void main(String[] args) {
Square s = new Square(10);
s.print();
s.setX(5);
s.print();
}
}

This produces the following output:

Square has sides of length 10 and 10
Square has sides of length 5 and 10

== Alternatives ==

=== Reverse the inheritance ===

Instead of having Square be a subclass of Rectangle, one could make Rectangle a subclass of Square. Afterall, you could say a Rectangle is a specialization of Square in which the sides don't need to be of the same length. Thus Square would define a constructor that takes only argument x. Rectangle could support that constructor and also provide another constructor which takes x and y. Likewise, Square could have only a setx method whereas Rectangle could also define a sety method.

This is somewhat of a contrived example since Square does not have any additional information than Rectangle. Such may not be the case in more realistic scenarios.

=== Absent constructor ===

The derived Rectangle class could choose to not provide an implementation for the constructor that takes arguments x and y. This would prevent any caller from instantiating an instance of Square with arguments x and y. This design maybe controversial since one normally expects a subclass to support all the constructors of the base class.

=== Throw exception ===

The Square class could override any methods or constructors which violate the contract and throw an exception. In the constructor example above, it could throw an exception if the lengths provided for x and y are not equal. In the setx method example, it could check the value of y and throw an exception if the passed in value for x wasn't equal to y. This is somewhat dubious but does allow the setx method to be called if the value isn't changing.

In Java the [http://download.oracle.com/javase/1.5.0/docs/api/java/lang/UnsupportedOperationException.html UnsupportedOperationException] could be thrown, which is a [http://download.oracle.com/javase/1.5.0/docs/api/java/lang/RuntimeException.html RuntimeException] and therefore does not need to be declared. If another type of exception was thrown, it would have to be declared.

=== Return new value ===

In this solution, the super class method would need to return its new value X when a method is called to change it. The derived class reacts by stubbornly just returning its current value, thus forcing the caller to use a method supported for that class. This solution avoids throwing exceptions but could have undesireable consequences if the calling code is not careful to check the return value to make sure it was modified. But perhaps worse, it requires the method signatures to be changed in the base class to support the problem in the derived class.

=== Make method more powerful ===

The implementation for the setx method in Square could just change the value of y also. This results in the method becoming more powerful, and might not be what the caller intended.

=== Return instance of new class ===

If the constructor is called with different values for x and y, or if the setx method is called, the implementation on Square could instantiate an instance of Rectangle and return that instead. This requires the methods to declare a return type of the base class. This could have unexpected consequences on the program.

=== Use separate immutable and mutable classes ===

In this approach, the Rectangle class is [http://en.wikipedia.org/wiki/Immutable_object immutable] and therefore its methods cannot change derived instances, they can only return new instances of Rectangle. A separate MutableRectangle class could be defined and all the modifiers put into it.

As in some of the previous solutions, this has the disadvantage of requiring significant modifications to the design of the base class. It also requires the calling code to perform more assignments and may result in more memory being consumed by all the immutable instances around.

=== Initialize base class as mutable/immutable ===

This is similar to the above but not requiring separate mutable and immutable classes. Rectangle could be initialized, presumably by a constructor, with a state indicating if it can be modified. The modifier methods would check this state to see if the operation was allowed.

== See also ==

* [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse Problem] (Wikipedia)
* [http://en.wikipedia.org/wiki/Anti-pattern Anti-Patterns] (Wikipedia)

== References ==

* Robert C. Martin, [http://www.objectmentor.com/resources/articles/lsp.pdf The Liskov Substitution Principle], C++ Report, March 1996.
* Jean-Luc Hainaut, Jean-Marc Hick, Vincent Englebert, Jean Henrard, Didier Roland: Understanding Implementations of IS-A Relations. ER 1996: 42-57

File:Square-rectangle.gif

2010-12-01T15:10:12Z

Mwroda:

CSC/ECE 517 Fall 2010/ch7 7g mr

2010-12-01T14:48:20Z

Mwroda:

= Square-Rectangle Anti-Pattern =

The Square-Rectangle [http://en.wikipedia.org/wiki/Anti-pattern Anti-Pattern] is a software development problem that can occur in [http://en.wikipedia.org/wiki/Object_oriented_programming Object Oriented Programming] with inheritance when a base class contains methods which invalidate the derived class, and thereby violate the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle].

== Description ==

Consider classes Rectangle and Square. By the [http://en.wikipedia.org/wiki/Is-a 'is a'] test, one might reasonably define the Square class as a specialization of the Rectangle class (Square is a Rectangle), where all sides are of equal length. But suppose Rectangle defines a constructor that takes two arguments, x and y, for the lengths of the sides. How can Square provide an implementation for this constructor? If the values passed for x and y are not the same, it would be unable to construct an instance of Square that satisfied the input criteria.

The situation is worse for modifier methods on the base class. Suppose Rectangle has a method setX which modifies only two sides of the rectangle. When called on a Square, it would cause the object to no longer be a square. This can be particularly problematic when new modifiers are added to an existing base class after it has been subclassed. If it has been subclassed improperly, the subclasses may be broken by the new functionality in the base class.

== Example ==

The following example illustrates the problem. In this case, Square has decided not to implement a constructor defined in Rectangle. But there is still a problem with the setX modifier:

class Rectangle
{
protected int x, y;

Rectangle() {}

Rectangle(int x, int y) {
this.x = x;
this.y = y;
}

void setX(int x) {
this.x = x;
}

void print() {
System.out.println(this.getClass().getName() + " has sides of length " + x + " and " + y);
}
}

public class Square extends Rectangle
{
Square(int x) {
this.x = x;
this.y = x;
}

public static void main(String[] args) {
Square s = new Square(10);
s.print();
s.setX(5);
s.print();
}
}

This produces the following output:

Square has sides of length 10 and 10
Square has sides of length 5 and 10

== Alternatives ==

=== Reverse the inheritance ===

Instead of having Square be a subclass of Rectangle, one could make Rectangle a subclass of Square. Afterall, you could say a Rectangle is a specialization of Square in which the sides don't need to be of the same length. Thus Square would define a constructor that takes only argument x. Rectangle could support that constructor and also provide another constructor which takes x and y. Likewise, Square could have only a setx method whereas Rectangle could also define a sety method.

This is somewhat of a contrived example since Square does not have any additional information than Rectangle. Such may not be the case in more realistic scenarios.

=== Absent constructor ===

The derived Rectangle class could choose to not provide an implementation for the constructor that takes arguments x and y. This would prevent any caller from instantiating an instance of Square with arguments x and y. This design maybe controversial since one normally expects a subclass to support all the constructors of the base class.

=== Throw exception ===

The Square class could override any methods or constructors which violate the contract and throw an exception. In the constructor example above, it could throw an exception if the lengths provided for x and y are not equal. In the setx method example, it could check the value of y and throw an exception if the passed in value for x wasn't equal to y. This is somewhat dubious but does allow the setx method to be called if the value isn't changing.

In Java the UnsupportedOperationException could be thrown, which is a RuntimeException and therefore does not need to be declared. If another type of exception was thrown, it would have to be declared.

=== Return new value ===

In this solution, the super class method would need to return its new value X when a method is called to change it. The derived class reacts by stubbornly just returning its current value, thus forcing the caller to use a method supported for that class. This solution avoids throwing exceptions but could have undesireable consequences if the calling code is not careful to check the return value to make sure it was modified. But perhaps worse, it requires the method signatures to be changed in the base class to support the problem in the derived class.

=== Make method more powerful ===

The implementation for the setx method in Square could just change the value of y also. This results in the method becoming more powerful, and might not be what the caller intended.

=== Return instance of new class ===

If the constructor is called with different values for x and y, or if the setx method is called, the implementation on Square could instantiate an instance of Rectangle and return that instead. This requires the methods to declare a return type of the base class. This could have unexpected consequences on the program.

=== Use separate immutable and mutable classes ===

In this approach, the Rectangle class is [http://en.wikipedia.org/wiki/Immutable_object immutable] and therefore its methods cannot change derived instances, they can only return new instances of Rectangle. A separate MutableRectangle class could be defined and all the modifiers put into it.

As in some of the previous solutions, this has the disadvantage of requiring significant modifications to the design of the base class. It also requires the calling code to perform more assignments and may result in more memory being consumed by all the immutable instances around.

=== Initialize base class as mutable/immutable ===

This is similar to the above but not requiring separate mutable and immutable classes. Rectangle could be initialized, presumably by a constructor, with a state indicating if it can be modified. The modifier methods would check this state to see if the operation was allowed.

== See also ==

* [http://en.wikipedia.org/wiki/Circle-ellipse_problem Circle-Ellipse Problem] (Wikipedia)
* [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle] (Wikipedia)

== References ==

CSC/ECE 517 Fall 2010/ch7 7g mr

2010-11-30T03:25:32Z

Mwroda:

= Square-Rectangle Anti-Pattern =

The Square-Rectangle [http://en.wikipedia.org/wiki/Anti-pattern Anti-Pattern] is a software development problem that can occur in [http://en.wikipedia.org/wiki/Object_oriented_programming Object Oriented Programming] when using inheritance.

== Description ==

Consider classes Rectangle and Square. One might reasonably define the Square class as a specific type of the Rectangle class since it passes the 'is a' test (Square is a Rectangle). This leads to several problems however, since subclasses are supposed to support all the methods of their super class.

== Examples ==

=== Constructor ===

Conceptually this problem happens when the base class contains more information than the derived class. In the example of the Square and the Rectangle, both have two sides x and y, but in the case of a Rectangle the sides may be of different length and therefore two values must be maintained.

Within the code the base class Rectangle may have a constructor that accepts two parameters, x and y, to set the length of its sides. How is the Square class to implement this constructor? It could override the constructor but if the values passed for x and y are not the same, it would be unable to construct an instance of Square that satisfied the input criteria.

=== Mutating Methods ===

The situation is likewise for mutating methods, which modif an object which was already instantiated. For example the Rectangle class may have a method setX which modifies the size of only one side of the rectangle. When called on a Square, it would cause the object to no longer be a square.

This becomes particularly problematic when new methods are added to an existing base class after it has been subclassed. If it has been subclassed improperly, the subclasses may be broken by the new functionality in the base class.

== Alternatives ==

=== Reverse the inheritance ===

Instead of having Square be a subclass of Rectangle, one could make Rectangle a subclass of Square. Afterall, you could say a Rectangle is a specialization of Square in which the sides don't need to be of the same length. Thus Square would define a constructor that takes only argument x. Rectangle could support that constructor and also provide another constructor which takes x and y. Likewise, Square could have only a setx method whereas Rectangle could also define a sety method.

This is somewhat of a contrived example since Square does not have any additional information than Rectangle. Such may not be the case in more realistic scenarios.

=== Absent constructor ===

The derived Rectangle class could just choose not to implement the constructor that takes arguments x and y. This would prevent any caller from instantiating an instance of Square with arguments x and y. This is confusing though, since one normally expects a subclass to support all the constructors of the base class.

=== Throw exception ===

The Square class could override any methods or constructors which violate the contract and throw an exception. In the constructor example above, it could throw an exception if the lengths provided for x and y are not equal. In the setx method example, it could check the value of y and throw an exception if the passed in value for x wasn't equal to y. This is somewhat dubious but does allow the setx method to be called if the value isn't changing.

In Java the UnsupportedOperationException could be thrown, which is a RuntimeException and therefore does not need to be declared. If another type of exception was thrown, it would have to be declared.

=== Return new value ===

In this solution, the super class method would need to return its new value X when a method is called to change it. The derived class reacts by stubbornly just returning its current value, thus forcing the caller to use a method supported for that class. This solution avoids throwing exceptions but could have undesireable consequences if the calling code is not careful to check the return value to make sure it was modified. But perhaps worse, it requires the method signatures to be changed in the base class to support the problem in the derived class.

=== Make method more powerful ===

The implementation for the setx method in Square could just change the value of y also. This results in the method becoming more powerful, and might not be what the caller intended.

=== Return instance of new class ===

If the constructor is called with different values for x and y, or if the setx method is called, the implementation on Square could instantiate an instance of Rectangle and return that instead. This requires the methods to declare a return type of the base class. This could have unexpected consequences on the program.

=== Make all classes immutable ===

In this approach, the classes are [http://en.wikipedia.org/wiki/Immutable_object immutable] and therefore the methods cannot change the existing class, they can only return new instances of the proper class. As in some of the previous solutions, this has the disadvantage of requiring significant modifications to the design of the base class. It also requires the calling code to perform more assignments and may result in more memory being consumed by all the immutable instances around.

== See also ==

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch7 7g mr

2010-11-30T02:39:04Z

Mwroda:

= Square Rectangle Anti-Pattern =

The Square Rectangle Anti-Pattern is a software development problem that can occur specifically in Object Oriented Programming when subclassing.

== Description ==

Consider classes Rectangle and Square. One might reasonably define the Square class as a specific type of the Rectangle class since it passes the 'is a' test (Square is a Rectangle). This leads to several problems however, since subclasses are supposed to support all the methods of their super class.

== Examples ==

=== Constructor ===

Conceptually this problem happens when the base class contains more information than the derived class. In the example of the Square and the Rectangle, both have two sides x and y, but in the case of a Rectangle the sides may be of different length and therefore two values must be maintained.

Within the code the base class Rectangle may have a constructor that accepts two parameters, x and y, to set the length of its sides. How is the Square class to implement this constructor? It could override the constructor but if the values passed for x and y are not the same, it would be unable to construct an instance of Square that satisfied the input criteria.

=== Mutating Methods ===

The situation is likewise for mutating methods, which modif an object which was already instantiated. For example the Rectangle class may have a method setX which modifies the size of only one side of the rectangle. When called on a Square, it would cause the object to no longer be a square.

This becomes particularly problematic when new methods are added to an existing base class after it has been subclassed. If it has been subclassed improperly, the subclasses may be broken by the new functionality in the base class.

== Alternatives ==

=== Reverse the inheritance ===

Instead of having Square be a subclass of Rectangle, one could make Rectangle a subclass of Square. Afterall, you could say a Rectangle is a specialization of Square in which the sides don't need to be of the same length. Thus Square would define a constructor that takes only argument x. Rectangle could support that constructor and also provide another constructor which takes x and y. Likewise, Square could have only a setx method whereas Rectangle could also define a sety method.

This is somewhat of a contrived example since Square does not have any additional information than Rectangle. Such may not be the case in more realistic scenarios.

=== Absent Constructor ===

The derived Rectangle class could just choose not to implement the constructor that takes arguments x and y. This would prevent any caller from instantiating an instance of Square with arguments x and y. This is confusing though, since one normally expects a subclass to support all the constructors of the base class.

=== Throw Exception ===

The Square class could override any methods or constructors which violate the contract and throw an exception. In the constructor example above, it could throw an exception if the lengths provided for x and y are not equal. In the setx method example, it could check the value of y and throw an exception if the passed in value for x wasn't equal to y. This is somewhat dubious but does allow the setx method to be called if the value isn't changing.

In Java the UnsupportedOperationException could be thrown, which is a RuntimeException and therefore does not need to be declared. If another type of exception was thrown, it would have to be declared.

=== Return new value ===

In this solution, the super class method would need to return its new value X when a method is called to change it. The derived class reacts by stubbornly just returning its current value, thus forcing the caller to use a method supported for that class. This solution avoids throwing exceptions but could have undesireable consequences if the calling code is not careful to check the return value to make sure it was modified. But perhaps worse, it requires the method signatures to be changed in the base class to support the problem in the derived class.

=== Make method more powerful ===

The implementation for the setx method in Square could just change the value of y also. This results in the method becoming more powerful, and might not be what the caller intended.

=== Convert Square to Rectangle ===

If the constructor is called with different values for x and y, or if the setx method is called, the implementation on Square could instantiate an instance of Rectangle and return that instead. This requires the methods to declare a return type of the base class. This could have unexpected consequences on the program.

=== Make all classes immutable ===

In this approach, the classes are immutable and therefore the methods cannot change the existing class, they can only return new instances of the proper class. As in some of the previous solutions, this has the disadvantage of requiring significant modifications to the design of the base class. It also requires the calling code to perform more assignments and may result in more memory being consumed by all the immutable instances around.

== See also ==

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-13T15:50:27Z

Mwroda: /* External Links */

= Aspect-oriented programming and AspectR =

'''AspectR''' is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming] (AOP) for Ruby programs by providing ways to wrap code around existing methods in a program. It is similar in functionality to and shares terminology with the [http://en.wikipedia.org/wiki/AspectJ AspectJ] library for Java.

AspectR was developed by Avi Bryant and Robert Feldt; it is distributed under the GNU General Public License [1].

== Overview of AOP ==

Aspect-Oriented Programming is an approach to modularizing code that ''cross-cuts'' the core components or business logic of a program [2]. Logging is a classical example of a ''concern'' which cross-cuts the core components of a program, and thus violates the widely held principle on Separation of Concerns. AOP solves this problem and is complimentary to Object Oriented Programming because it allows the concerns which cuts across the program to be encapsulated into their own classes, called aspects.

[[Image:Aop.GIF]]

==== Motivation ====

Consider the following exercise...

: 1. Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

: 2. Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

: 3. Make the same changes to other business logic methods throughout the program.

: 4. Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [3]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

Unlike AspectR, the aspects in AspectJ programs must be transformed into valid Java code.

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing.

Unlike AspectJ, however, AspectR does not require a separate language processor to coordinate the composition of program from the aspects and the business logic code.

== References ==
# AspectR README. http://aspectr.sourceforge.net/ January 29, 2002
# Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242.
# AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://ruby-doc.org/ Ruby Documentation]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Separation_of_concerns Separation of Concerns on Wikipedia]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-13T15:47:38Z

Mwroda:

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T19:47:26Z

Mwroda:

= Aspect-oriented programming and AspectR =

'''AspectR''' is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming] (AOP) for Ruby programs by providing ways to wrap code around existing methods in a program. It is similar in functionality to and shares terminology with the [http://en.wikipedia.org/wiki/AspectJ AspectJ] library for Java.

AspectR was developed by Avi Bryant and Robert Feldt; it is distributed under the GNU General Public License [1].

== Overview of AOP ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic of a program [2]. AOP is complimentary to Object Oriented Programming because it allows those concerns which cut across the program to be encapsulated into their own classes, called aspects.

[[Image:Aop.GIF]]

==== Motivation ====

Consider the following exercise...

: 1. Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

: 2. Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

: 3. Make the same changes to other business logic methods throughout the program.

: 4. Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [3]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

Unlike AspectR, the aspects in AspectJ programs must be transformed into valid Java code.

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing. Unlike AspectJ, however, AspectR conveniently does not require an intermediate step to generate the Java source code from the AspectJ code.

== References ==
# AspectR README. http://aspectr.sourceforge.net/ January 29, 2002
# Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242.
# AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://ruby-doc.org/ Ruby Documentation]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Model_view_controller]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T19:45:32Z

Mwroda: /* References */

= Aspect-oriented programming and AspectR =

'''AspectR''' is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming] for Ruby programs by providing ways to wrap code around existing methods in a program. It is similar in functionality to and shares terminology with the [http://en.wikipedia.org/wiki/AspectJ AspectJ] library for Java.

AspectR was developed by Avi Bryant and Robert Feldt; it is distributed under the GNU General Public License [1].

== Aspect-Oriented Programming ==

Aspect-Oriented Programming (AOP) is an approach to modularizing concerns that cut across the core concerns or business logic of a program [2]. AOP is complimentary to Object Oriented Programming because it allows those concerns which cut across the program to be encapsulated into their own classes, called aspects.

[[Image:Aop.GIF]]

==== Motivation ====

Consider the following exercise...

: 1. Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

: 2. Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

: 3. Make the same changes to other business logic methods throughout the program.

: 4. Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [3]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

Unlike AspectR, the aspects in AspectJ programs must be transformed into valid Java code.

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing. Unlike AspectJ, however, AspectR conveniently does not require an intermediate step to generate the Java source code from the AspectJ code.

== References ==
# AspectR README. http://aspectr.sourceforge.net/ January 29, 2002
# Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242.
# AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://ruby-doc.org/ Ruby Documentation]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Model_view_controller]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T19:44:53Z

Mwroda:

= Aspect-oriented programming and AspectR =

'''AspectR''' is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming] for Ruby programs by providing ways to wrap code around existing methods in a program. It is similar in functionality to and shares terminology with the [http://en.wikipedia.org/wiki/AspectJ AspectJ] library for Java.

AspectR was developed by Avi Bryant and Robert Feldt; it is distributed under the GNU General Public License [1].

== Aspect-Oriented Programming ==

Aspect-Oriented Programming (AOP) is an approach to modularizing concerns that cut across the core concerns or business logic of a program [2]. AOP is complimentary to Object Oriented Programming because it allows those concerns which cut across the program to be encapsulated into their own classes, called aspects.

[[Image:Aop.GIF]]

==== Motivation ====

Consider the following exercise...

: 1. Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

: 2. Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

: 3. Make the same changes to other business logic methods throughout the program.

: 4. Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [3]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

Unlike AspectR, the aspects in AspectJ programs must be transformed into valid Java code.

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing. Unlike AspectJ, however, AspectR conveniently does not require an intermediate step to generate the Java source code from the AspectJ code.

== References ==
1. AspectR README. http://aspectr.sourceforge.net/ January 29, 2002
2. Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242.
3. AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://ruby-doc.org/ Ruby Documentation]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Model_view_controller]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T19:39:51Z

Mwroda:

= Aspect-oriented programming and AspectR =

'''AspectR''' is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming] for Ruby programs by providing ways to wrap code around existing methods in a program. Similar to the AspectJ library for Java, AspectR was developed by Avi Bryant and Robert Feldt [1], and distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming (AOP) is an approach to modularizing concerns that cut across the core concerns or business logic of a program. AOP is complimentary to Object Oriented Programming because it allows those concerns which cut across the program to be encapsulated into their own classes, called aspects.

[[Image:Aop.GIF]]

==== Motivation ====

Consider the following exercise...

: 1. Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

: 2. Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

: 3. Make the same changes to other business logic methods throughout the program.

: 4. Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [2]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

Unlike AspectR, the aspects in AspectJ programs must be transformed into valid Java code.

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing. Unlike AspectJ, however, AspectR conveniently does not require an intermediate step to generate the Java source code from the AspectJ code.

== References ==
1. AspectR README. http://aspectr.sourceforge.net/ January 29, 2002
2. AspectR Ruby documentation (RDoc), AspectR module
3. Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242.

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://ruby-doc.org/ Ruby Documentation]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Model_view_controller]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T19:39:16Z

Mwroda: /* Motivation */

= Aspect-oriented programming and AspectR =

'''AspectR''' is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming] for Ruby programs by providing ways to wrap code around existing methods in a program. Similar to the AspectJ library for Java, AspectR was developed by Avi Bryant and Robert Feldt [1], and distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming (AOP) is an approach to modularizing concerns that cut across the core concerns or business logic of a program. AOP is complimentary to Object Oriented Programming because it allows those concerns which cut across the program to be encapsulated into their own classes, called aspects.

==== Motivation ====

Consider the following exercise...

: 1. Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

: 2. Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

: 3. Make the same changes to other business logic methods throughout the program.

: 4. Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

[[Image:Aop.GIF]]

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [2]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

Unlike AspectR, the aspects in AspectJ programs must be transformed into valid Java code.

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing. Unlike AspectJ, however, AspectR conveniently does not require an intermediate step to generate the Java source code from the AspectJ code.

== References ==
1. AspectR README. http://aspectr.sourceforge.net/ January 29, 2002
2. AspectR Ruby documentation (RDoc), AspectR module
3. Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242.

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://ruby-doc.org/ Ruby Documentation]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Model_view_controller]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T19:38:50Z

Mwroda: /* Motivation */

= Aspect-oriented programming and AspectR =

'''AspectR''' is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming] for Ruby programs by providing ways to wrap code around existing methods in a program. Similar to the AspectJ library for Java, AspectR was developed by Avi Bryant and Robert Feldt [1], and distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming (AOP) is an approach to modularizing concerns that cut across the core concerns or business logic of a program. AOP is complimentary to Object Oriented Programming because it allows those concerns which cut across the program to be encapsulated into their own classes, called aspects.

==== Motivation ====

: 1. Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

: 2. Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

: 3. Make the same changes to other business logic methods throughout the program.

: 4. Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

[[Image:Aop.GIF]]

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [2]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

Unlike AspectR, the aspects in AspectJ programs must be transformed into valid Java code.

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing. Unlike AspectJ, however, AspectR conveniently does not require an intermediate step to generate the Java source code from the AspectJ code.

== References ==
1. AspectR README. http://aspectr.sourceforge.net/ January 29, 2002
2. AspectR Ruby documentation (RDoc), AspectR module
3. Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242.

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://ruby-doc.org/ Ruby Documentation]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Model_view_controller]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T19:36:29Z

Mwroda: /* Motivation */

= Aspect-oriented programming and AspectR =

'''AspectR''' is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming] for Ruby programs by providing ways to wrap code around existing methods in a program. Similar to the AspectJ library for Java, AspectR was developed by Avi Bryant and Robert Feldt [1], and distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming (AOP) is an approach to modularizing concerns that cut across the core concerns or business logic of a program. AOP is complimentary to Object Oriented Programming because it allows those concerns which cut across the program to be encapsulated into their own classes, called aspects.

==== Motivation ====

# Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

## Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

### Make the same changes to other business logic methods throughout the program.

#### Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

[[Image:Aop.GIF]]

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [2]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

Unlike AspectR, the aspects in AspectJ programs must be transformed into valid Java code.

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing. Unlike AspectJ, however, AspectR conveniently does not require an intermediate step to generate the Java source code from the AspectJ code.

== References ==
1. AspectR README. http://aspectr.sourceforge.net/ January 29, 2002
2. AspectR Ruby documentation (RDoc), AspectR module
3. Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242.

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://ruby-doc.org/ Ruby Documentation]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Model_view_controller]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T19:36:05Z

Mwroda: /* Motivation */

= Aspect-oriented programming and AspectR =

'''AspectR''' is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming] for Ruby programs by providing ways to wrap code around existing methods in a program. Similar to the AspectJ library for Java, AspectR was developed by Avi Bryant and Robert Feldt [1], and distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming (AOP) is an approach to modularizing concerns that cut across the core concerns or business logic of a program. AOP is complimentary to Object Oriented Programming because it allows those concerns which cut across the program to be encapsulated into their own classes, called aspects.

==== Motivation ====

# Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

# Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

# Make the same changes to other business logic methods throughout the program.

# Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

[[Image:Aop.GIF]]

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [2]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

Unlike AspectR, the aspects in AspectJ programs must be transformed into valid Java code.

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing. Unlike AspectJ, however, AspectR conveniently does not require an intermediate step to generate the Java source code from the AspectJ code.

== References ==
1. AspectR README. http://aspectr.sourceforge.net/ January 29, 2002
2. AspectR Ruby documentation (RDoc), AspectR module
3. Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242.

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://ruby-doc.org/ Ruby Documentation]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Model_view_controller]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T19:31:21Z

Mwroda:

= Aspect-oriented programming and AspectR =

'''AspectR''' is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming] for Ruby programs by providing ways to wrap code around existing methods in a program. Similar to the AspectJ library for Java, AspectR was developed by Avi Bryant and Robert Feldt [1], and distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming (AOP) is an approach to modularizing concerns that cut across the core concerns or business logic of a program. AOP is complimentary to Object Oriented Programming because it allows those concerns which cut across the program to be encapsulated into their own classes, called aspects.

==== Motivation ====

1 Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

1 Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

1 Make the same changes to other business logic methods throughout the program.

1 Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

[[Image:Aop.GIF]]

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [2]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

Unlike AspectR, the aspects in AspectJ programs must be transformed into valid Java code.

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing. Unlike AspectJ, however, AspectR conveniently does not require an intermediate step to generate the Java source code from the AspectJ code.

== References ==
1. AspectR README. http://aspectr.sourceforge.net/ January 29, 2002
2. AspectR Ruby documentation (RDoc), AspectR module
3. Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242.

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://ruby-doc.org/ Ruby Documentation]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Model_view_controller]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T18:11:44Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is similar in functionality to the AspectJ library for Java, except simpler, less well known, and less documented. AspectR is distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming (AOP) is an approach to modularizing concerns that cut across the core concerns or business logic of a program. AOP is complimentary to Object Oriented Programming because it allows those concerns which cut across the program to be encapsulated into their own classes, called aspects.

==== Motivation ====

1. Take a shopping cart application with a Cart class and method add_to_cart():

class Cart
has_many :items
def add_to_cart(item)
items << item
end
end

This code is easy to understand and maintain.

2. Now add security, database transactions, and logging code:

class Cart
has_many :items
def add_to_cart(item)
log('entering method')
check_permissions
conn = new_connection
begin
items << item
rescue
log('exception')
ensure
conn.close
end
log('leaving method')
end
end

3. Make the same changes to other business logic methods throughout the program.

4. Finally, try reusing this code in another application which has a different transaction framework, uses a different logging library, or handles security differently.

Aspect-Oriented Programming resolves this problem by encapsulating the concerns that cut across the program.

[[Image:Aop.GIF]]

=== Terminology ===

AspectR uses a lot of the same terminology as AspectJ.

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [1]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Examples ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== Summary ==

Although the library is quite small, AspectR is a useful tool for implementing Aspect-Oriented Programming in Ruby programs. The main limitation of the library is that it only supports wrapping methods with join points either before or after the method calls. More complex join points are not supported at the time of this writing. Unlike AspectJ, however, AspectR conveniently does not require an intermediate step to generate the Java source code from the AspectJ code.

== References ==
1. AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]
* [http://en.wikipedia.org/wiki/Model_view_controller]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-11T17:26:53Z

Mwroda: /* Aspect-Oriented Programming */

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the AspectJ library for Java, but less well known. AspectR is distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

[[Image:Aop.GIF]]

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [1]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== References ==
1. AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]

File:Aop.GIF

2010-10-11T17:25:32Z

Mwroda:

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-08T11:50:05Z

Mwroda: /* AspectR */

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the AspectJ library for Java, but less well known. AspectR is distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [1]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== References ==
1. AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-08T11:49:58Z

Mwroda: /* AspectR */

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the AspectJ library for Java, but less well known. AspectR is distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [1]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

The following code defines a class <code>SomeClass</code> and tests the aspect:

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== References ==
1. AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-08T11:48:51Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the AspectJ library for Java, but less well known. AspectR is distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [1]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}

after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== References ==
1. AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-08T11:47:59Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the AspectJ library for Java, but less well known. AspectR is distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [1]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

import java.util.Date;

aspect Profiler {
private Date beginTime;

pointcut myMethod(SomeClass s): target(s) && call(public * some*(..));

before(SomeClass s): myMethod(s) {
this.beginTime = new Date();
}
after(SomeClass s): myMethod(s) {
Date newTime = new Date();
int timeElapsed = this.beginTime.getTime() - newTime.getTime();
System.out.println(thisJoinPointStaticPart + " took " + timeElapsed + " secs");
}
}

== References ==
1. AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-06T13:23:32Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the AspectJ library for Java, but less well known. AspectR is distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change [1]:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==
1. AspectR Ruby documentation (RDoc), AspectR module

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-06T13:22:35Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the AspectJ library for Java, but less well known. AspectR is distributed under the GNU General Public License.<ref>"Adaptive Object Oriented Programming: The Demeter Approach with Propagation Patterns" ''Karl Liebherr'' 1996 ISBN 0-534-94602-X presents a well-worked version of essentially the same thing (Lieberherr subsequently recognized this and reframed his approach).</ref>

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change <ref>AspectR Ruby documentation (RDoc), AspectR module</ref>:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==
{{reflist}}

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-06T13:21:59Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the AspectJ library for Java, but less well known. AspectR is distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change <ref>AspectR Ruby documentation (RDoc), AspectR module</ref>:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==
{{reflist}}

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-06T13:18:23Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the AspectJ library for Java, but less well known. AspectR is distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change <ref>[[Edsger, Feldt]], AspectR Ruby documentation, AspectR module</ref>:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==
{{reflist}}

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-06T13:12:21Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables Aspect-oriented programming for Ruby programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the AspectJ library for Java, but less well known. AspectR is distributed under the GNU General Public License.

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

* [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-Oriented Programming on Wikipedia]
* [http://aspectr.sourceforge.net/ AspectR home page]
* [http://www.eclipse.org/aspectj/doc/released/progguide/index.html AspectJ Programming Guide]
* [http://ruby-doc.org/docs/ProgrammingRuby/html/ Programming Ruby - The Pragmatic Programmer's Guide]
* [http://en.wikipedia.org/wiki/GPL GNU Public License]

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-06T13:03:40Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-oriented programming] for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the [http://en.wikipedia.org/wiki/Aspectj AspectJ] library for Java, but less well known. AspectR is distributed under the [http://en.wikipedia.org/wiki/GPL GNU General Public License].

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

Code can be executed with dispatching by the API disabled using the <code>disable_advice_dispatching</code> instance method on the aspect class. Although temporary, the effect is global to the API. For example the following code will NOT result in the advice methods being called:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.disable_advice_dispatching { SomeClass.new.some_method }

One can test to see if the API dispatching is disabled using the Aspect class method <code>dispatch?</code>, for example:

Aspect.dispatch?

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-06T12:48:39Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-oriented programming] for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the [http://en.wikipedia.org/wiki/Aspectj AspectJ] library for Java, but less well known. AspectR is distributed under the [http://en.wikipedia.org/wiki/GPL GNU General Public License].

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

We then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>.

Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method using the <code>add_advice</code> method, for example:

profiler = Profiler.new

profiler.add_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.add_advice(SomeClass, :POST, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_start)
profiler.remove_advice(SomeClass, :POST, :some_method, :method_end)

We can wrap both the before and after join points, and specify multiple target methods, for example the following code will wrap all the methods from the class <code>SomeClass</code> which match the regular expression "/some/" with our advice methods for the before and after join points:

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

Similarly, this can be unwrapped:

profiler.unwrap(SomeClass, :method_start, :method_end, /some/)

Alternatively, you can have code directly injected into the beginning and ending of the target methods . This has performance advantages but cannot be unwrapped:

profiler.wrap_with_code(SomeClass, '@begin = Time.now', 'timeElapsed = Time.now - @begin; puts "took #{timeElapsed} secs"' , /some/)

To wrap methods from multiple target classes, the AspectR library defines a <code>wrap_classes</code> method. This is an experimental method and the API is likely to change:

wrap_classes(profiler, :method_start, :method_end, /Some/, /some/)

One can specify that one or more methods which should never be wrapped by passing in the beginning of the method name to the constructor. There is also a <code>wrappable?</code> method to test if a method can be wrapped. For example this code will result in the wrap being ignored and return true:

profiler = Profiler.new("some")

profiler.wrap(SomeClass, :method_start, :method_end, /some/)

profiler.wrappable?(:some_method)

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-06T11:51:31Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-oriented programming] for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the [http://en.wikipedia.org/wiki/Aspectj AspectJ] library for Java, but less well known. AspectR is distributed under the [http://en.wikipedia.org/wiki/GPL GNU General Public License].

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Borrowed from AspectJ terminology, refers to Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. For example, we define a new aspect class to implement a code profiler:

require aspectr.rb
include AspectR

class Profiler < Aspect
end

You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods.

def method_start(method, object, exitstatus, *args)
@begin = Time.now
end

def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end

profiler = Profiler.new

AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. Given the simple example,

class SomeClass
def some_method
puts "hello"
sleep 5
end
end

One can add advice to be invoked before or after a single target method as follows:

profiler.add_advice(SomeClass, :PRE, :some_method, :method_end)

This advice can be removed using <code>remove_advice</code>:

profiler.remove_advice(SomeClass, :PRE, :some_method, :method_end)

:The AspectR API provides the <code>add_advice</code> method to add an advice method to be invoked before or after a single target method.

To add an advice method to be invoked before or after a single target method, use the <code>add_advice</code> and <code>remove_advice</code> instance methods on the Aspect class:

add_advice (target, joinpoint, method, advice)

remove_advice (target, joinpoint, method, advice)

Parameters:
** <code>target</code> - target class
** <code>joinpoint</code> - must be either <code>PRE</code> or <code>POST</code>
** <code>method</code> - target method
** <code>advice</code> - advice method in the aspect class

To wrap both the before and after join points, and specify multiple target methods, use the <code>wrap</code> and <code>unwrap</code> instance methods on the Aspect class:

wrap (target, pre, post, *args)

unwrap (target, pre, post, *args)

Parameters:
* <code>target</code> - target class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>*args</code> - target methods, or regular expression matching method names in the target class

Alternatively, you may wrap target methods to blocks of advice code using the <code>wrap_with_code</code> instance method. Has performance advantages but cannot be unwrapped:

wrap_with_code (target, preCode, postCode, *args)

To wrap methods from multiple target classes, the AspectR library defines a global <code>wrap_classes</code> method. This is an experimental method and the API is likely to change:

wrap_classes (aspect, pre, post, classes, *methods)

Parameters:
* <code>aspect</code> - aspect class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>classes</code> - regular expression to match target class names
* <code>*methods</code> - target methods, or regular expression matching method names in the target classes

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> - Class method to create a new instance of the aspect class and specify methods that should never be wrapped.

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-06T11:30:59Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-oriented programming] for [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the [http://en.wikipedia.org/wiki/Aspectj AspectJ] library for Java, but less well known. AspectR is distributed under the [http://en.wikipedia.org/wiki/GPL GNU General Public License].

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

==== Motivation ====

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== The AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

To add an advice method to be invoked before or after a single target method, use the <code>add_advice</code> and <code>remove_advice</code> instance methods on the Aspect class:

add_advice (target, joinpoint, method, advice)

remove_advice (target, joinpoint, method, advice)

Parameters:
** <code>target</code> - target class
** <code>joinpoint</code> - must be either <code>PRE</code> or <code>POST</code>
** <code>method</code> - target method
** <code>advice</code> - advice method in the aspect class

To wrap both the before and after join points, and specify multiple target methods, use the <code>wrap</code> and <code>unwrap</code> instance methods on the Aspect class:

wrap (target, pre, post, *args)

unwrap (target, pre, post, *args)

Parameters:
* <code>target</code> - target class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>*args</code> - target methods, or regular expression matching method names in the target class

Alternatively, you may wrap target methods to blocks of advice code using the <code>wrap_with_code</code> instance method. Has performance advantages but cannot be unwrapped:

wrap_with_code (target, preCode, postCode, *args)

To wrap methods from multiple target classes, the AspectR library defines a global <code>wrap_classes</code> method. This is an experimental method and the API is likely to change:

wrap_classes (aspect, pre, post, classes, *methods)

Parameters:
* <code>aspect</code> - aspect class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>classes</code> - regular expression to match target class names
* <code>*methods</code> - target methods, or regular expression matching method names in the target classes

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> - Class method to create a new instance of the aspect class and specify methods that should never be wrapped.

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-06T11:27:22Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a programming library that enables [http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect-oriented programming] [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] programs by providing ways to wrap code around existing methods in a program. It is simpler but similar in functionality to the [http://en.wikipedia.org/wiki/Aspectj AspectJ] library for Java, but less well known. AspectR is distributed under the [http://en.wikipedia.org/wiki/GPL GNU General Public License].

== Aspect-Oriented Programming ==

Aspect-Oriented Programming is an approach to modularizing concerns that cut across the core concerns or business logic, of a program.

=== Motivation ===

The model code in a typical program will often contain not only the business logic but also secondary concerns such as transactions, security, logging, etc. This clutters the code in the model, making it hard to distinguish the business logic from the secondary code, complicating maintenance and reuse. Furthermore, these secondary concerns cut across multiple core concerns in the program, which violates the separation of concerns. As a result, changing to a different transaction API, for example, results in code modifications throughout the program.

=== Terminology ===

* Aspects - Classes that implement functionality needed in many parts of a program, but are not part of the business logic or core concern of the program.

* Advice - Aspect methods or code to be applied around existing business logic.

* Join Point - Places in the core business logic that advice should be applied or wrapped around.

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

To add an advice method to be invoked before or after a single target method, use the <code>add_advice</code> and <code>remove_advice</code> instance methods on the Aspect class:

add_advice (target, joinpoint, method, advice)

remove_advice (target, joinpoint, method, advice)

Parameters:
* <code>target</code> - target class
* <code>joinpoint</code> - must be either <code>PRE</code> or <code>POST</code>
* <code>method</code> - target method
* <code>advice</code> - advice method in the aspect class

To wrap both the before and after join points, and specify multiple target methods, use the <code>wrap</code> and <code>unwrap</code> instance methods on the Aspect class:

wrap (target, pre, post, *args)

unwrap (target, pre, post, *args)

Parameters:
* <code>target</code> - target class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>*args</code> - target methods, or regular expression matching method names in the target class

Alternatively, you may wrap target methods to blocks of advice code using the <code>wrap_with_code</code> instance method. Has performance advantages but cannot be unwrapped:

wrap_with_code (target, preCode, postCode, *args)

To wrap methods from multiple target classes, the AspectR library defines a global <code>wrap_classes</code> method. This is an experimental method and the API is likely to change:

wrap_classes (aspect, pre, post, classes, *methods)

Parameters:
* <code>aspect</code> - aspect class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>classes</code> - regular expression to match target class names
* <code>*methods</code> - target methods, or regular expression matching method names in the target classes

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> - Class method to create a new instance of the aspect class and specify methods that should never be wrapped.

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T15:36:05Z

Mwroda: /* Methods for wrapping */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

To add an advice method to be invoked before or after a single target method, use the <code>add_advice</code> and <code>remove_advice</code> instance methods on the Aspect class:

add_advice (target, joinpoint, method, advice)

remove_advice (target, joinpoint, method, advice)

Parameters:
* <code>target</code> - target class
* <code>joinpoint</code> - must be either <code>PRE</code> or <code>POST</code>
* <code>method</code> - target method
* <code>advice</code> - advice method in the aspect class

To wrap both the before and after join points, and specify multiple target methods, use the <code>wrap</code> and <code>unwrap</code> instance methods on the Aspect class:

wrap (target, pre, post, *args)

unwrap (target, pre, post, *args)

Parameters:
* <code>target</code> - target class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>*args</code> - target methods, or regular expression matching method names in the target class

Alternatively, you may wrap target methods to blocks of advice code using the <code>wrap_with_code</code> instance method. Has performance advantages but cannot be unwrapped:

wrap_with_code (target, preCode, postCode, *args)

To wrap methods from multiple target classes, the AspectR library defines a global <code>wrap_classes</code> method. This is an experimental method and the API is likely to change:

wrap_classes (aspect, pre, post, classes, *methods)

Parameters:
* <code>aspect</code> - aspect class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>classes</code> - regular expression to match target class names
* <code>*methods</code> - target methods, or regular expression matching method names in the target classes

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> - Class method to create a new instance of the aspect class and specify methods that should never be wrapped.

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T15:35:31Z

Mwroda: /* Methods for wrapping */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

To add an advice method to be invoked before or after a single target method, use the <code>add_advice</code> and <code>remove_advice</code> instance methods on the Aspect class:

add_advice (target, joinpoint, method, advice)

remove_advice (target, joinpoint, method, advice)

Parameters:
* <code>target</code> - target class
* <code>joinpoint</code> - must be either <code>PRE</code> or <code>POST</code>
* <code>method</code> - target method
* <code>advice</code> - advice method in the aspect class

To wrap both the before and after join points, and specify multiple target methods, use the <code>wrap</code> and <code>unwrap</code> instance methods on the Aspect class:

wrap (target, pre, post, *args)

unwrap (target, pre, post, *args)

Parameters:
* <code>target</code> - target class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>*args</code> - target methods, or regular expression matching method names in the target class

Alternatively, you may wrap target methods to blocks of advice code using the <code>wrap_with_code</code> instance method. Has performance advantages but cannot be unwrapped:

<code>wrap_with_code (target, preCode, postCode, *args)</code>

To wrap methods from multiple target classes, the AspectR library defines a global <code>wrap_classes</code> method. This is an experimental method and the API is likely to change:

<code>wrap_classes (aspect, pre, post, classes, *methods)</code

Parameters:
* <code>aspect</code> - aspect class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>classes</code> - regular expression to match target class names
* <code>*methods</code> - target methods, or regular expression matching method names in the target classes

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> - Class method to create a new instance of the aspect class and specify methods that should never be wrapped.

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T15:31:41Z

Mwroda: /* Methods for wrapping */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

To wrap only one join point (before or after method invocation) for a single method in a target class to an advice method in the aspect class, use the <code>add_advice</code> and <code>remove_advice</code> instance methods on the Aspect class:

<code>add_advice (target, joinpoint, method, advice)</code>

<code>remove_advice (target, joinpoint, method, advice)</code>

Parameters:
* <code>target</code> - target class
* <code>joinpoint</code> - must be either <code>PRE</code> or <code>POST</code>
* <code>method</code> - target method
* <code>advice</code> - advice method in the aspect class

To wrap both the before and after join points, and specify multiple target methods, use the <code>wrap</code> and <code>unwrap</code> instance methods on the Aspect class:

<code>wrap (target, pre, post, *args)</code>

<code>unwrap (target, pre, post, *args)</code>

Parameters:
* <code>target</code> - target class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>*args</code> - target methods, or regular expression matching method names in the target class

Alternatively, you may wrap target methods to blocks of advice code using the <code>wrap_with_code</code> instance method. Has performance advantages but cannot be unwrapped:

<code>wrap_with_code (target, preCode, postCode, *args)</code>

To wrap methods from multiple target classes, the AspectR library defines a global <code>wrap_classes</code> method. This is an experimental method and the API is likely to change:

<code>wrap_classes (aspect, pre, post, classes, *methods)</code

Parameters:
* <code>aspect</code> - aspect class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>classes</code> - regular expression to match target class names
* <code>*methods</code> - target methods, or regular expression matching method names in the target classes

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> - Class method to create a new instance of the aspect class and specify methods that should never be wrapped.

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T15:23:30Z

Mwroda: /* Methods for wrapping */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

To wrap only one join point (before or after method invocation) for a single method in a target class to an advice method in the aspect class, use the <code>add_advice</code> and <code>remove_advice</code> instance methods on the Aspect class:

<code>add_advice (target, joinpoint, method, advice)</code>

<code>remove_advice (target, joinpoint, method, advice)</code>

Parameters:
* <code>target</code> - target class
* <code>joinpoint</code> - must be either <code>PRE</code> or <code>POST</code>
* <code>method</code> - target method
* <code>advice</code> - advice method in the aspect class

To wrap both the before and after join points, and specify multiple target methods, use the <code>wrap</code> and <code>unwrap</code> instance methods on the Aspect class:

<code>wrap (target, pre, post, *args)</code>
<code>unwrap (target, pre, post, *args)</code>

Parameters:
* <code>target</code> - target class
* <code>pre</code> - advice method to call before target method invocations
* <code>post</code> - advice method to call after target method invocations
* <code>*args</code> - target methods, or regular expression matching method names in the target class

* <code>wrap_with_code (target, preCode, postCode, *args) </code>

* <code>wrap_classes (aspect, pre, post, classes, *methods)</code> - More flexible yet experimental version of the <code>wrap<code> method to wrap methods in multiple classes. Caller must provide the aspect object and regular expression used to match target classes. The rest of the parameters are the same as the <code>wrap</code> method. Note that this API is likely to change in future versions of AspectR.

* <code>add_advice (target, joinpoint, method, advice)</code> - Allows you to specify an advice method to be called when the joinpoint is reached in the specified target class and method. Joinpoint must be either <code>PRE</code> or <code>POST</code>.

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> - Class method to create a new instance of the aspect class and specify methods that should never be wrapped.

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T15:18:37Z

Mwroda: /* Methods for wrapping */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

To wrap only one join point (before or after method invocation) for a single method in a target class to an advice method in the aspect class, use the following methods:

<code>add_advice (target, joinpoint, method, advice)</code>
<code>remove_advice (target, joinpoint, method, advice)</code>

Parameters:
* <code>target</code> - target class
* <code>joinpoint</code> - must be either <code>PRE</code> or <code>POST</code>
* <code>method</code> - target method
* <code>advice</code> - advice method in the aspect class

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

* <code>wrap (target, pre, post, *args)</code> - Instance method of the aspect class which allows you to specify an advice method in the aspect class to be invoked before and after each intercepted method, along with the target class and an <code>*args</code> parameter which may contain the methods in the target class to intercept, or a regular expression to match method names in the target class.

* <code>unwrap (target, pre, post, *args)</code> - Undoes a wrapping made with the previous method.

* <code>wrap_with_code (target, preCode, postCode, *args) </code>

* <code>wrap_classes (aspect, pre, post, classes, *methods)</code> - More flexible yet experimental version of the <code>wrap<code> method to wrap methods in multiple classes. Caller must provide the aspect object and regular expression used to match target classes. The rest of the parameters are the same as the <code>wrap</code> method. Note that this API is likely to change in future versions of AspectR.

* <code>add_advice (target, joinpoint, method, advice)</code> - Allows you to specify an advice method to be called when the joinpoint is reached in the specified target class and method. Joinpoint must be either <code>PRE</code> or <code>POST</code>.

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> - Class method to create a new instance of the aspect class and specify methods that should never be wrapped.

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T15:16:00Z

Mwroda: /* Methods for wrapping */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

To wrap only one join point (before or after method invocation) for a single method in a target class to an advice method in the aspect class, use the following methods:

* <code>add_advice (target, joinpoint, method, advice)</code> - <code>target</code> class, <code>joinpoint</code> must be either <code>PRE</code> or <code>POST</code>, <code>method</code> in the target class, <code>advice</code> method in the aspect class.

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

* <code>wrap (target, pre, post, *args)</code> - Instance method of the aspect class which allows you to specify an advice method in the aspect class to be invoked before and after each intercepted method, along with the target class and an <code>*args</code> parameter which may contain the methods in the target class to intercept, or a regular expression to match method names in the target class.

* <code>unwrap (target, pre, post, *args)</code> - Undoes a wrapping made with the previous method.

* <code>wrap_with_code (target, preCode, postCode, *args) </code>

* <code>wrap_classes (aspect, pre, post, classes, *methods)</code> - More flexible yet experimental version of the <code>wrap<code> method to wrap methods in multiple classes. Caller must provide the aspect object and regular expression used to match target classes. The rest of the parameters are the same as the <code>wrap</code> method. Note that this API is likely to change in future versions of AspectR.

* <code>add_advice (target, joinpoint, method, advice)</code> - Allows you to specify an advice method to be called when the joinpoint is reached in the specified target class and method. Joinpoint must be either <code>PRE</code> or <code>POST</code>.

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> - Class method to create a new instance of the aspect class and specify methods that should never be wrapped.

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T15:01:27Z

Mwroda: /* Specifying methods that should never be wrapped */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

* <code>wrap (target, pre, post, *args)</code> - Instance method of the aspect class which allows you to specify an advice method in the aspect class to be invoked before and after each intercepted method, along with the target class and an <code>*args</code> parameter which may contain the methods in the target class to intercept, or a regular expression to match method names in the target class.

* <code>unwrap (target, pre, post, *args)</code> - Undoes a wrapping made with the previous method.

* <code>wrap_with_code (target, preCode, postCode, *args) </code>

* <code>wrap_classes (aspect, pre, post, classes, *methods)</code> - More flexible yet experimental version of the <code>wrap<code> method to wrap methods in multiple classes. Caller must provide the aspect object and regular expression used to match target classes. The rest of the parameters are the same as the <code>wrap</code> method. Note that this API is likely to change in future versions of AspectR.

* <code>add_advice (target, joinpoint, method, advice)</code> - Allows you to specify an advice method to be called when the joinpoint is reached in the specified target class and method. Joinpoint must be either <code>PRE</code> or <code>POST</code>.

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> - Class method to create a new instance of the aspect class and specify methods that should never be wrapped.

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T14:58:55Z

Mwroda: /* Methods for controlling dispatching */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

* <code>wrap (target, pre, post, *args)</code> - Instance method of the aspect class which allows you to specify an advice method in the aspect class to be invoked before and after each intercepted method, along with the target class and an <code>*args</code> parameter which may contain the methods in the target class to intercept, or a regular expression to match method names in the target class.

* <code>unwrap (target, pre, post, *args)</code> - Undoes a wrapping made with the previous method.

* <code>wrap_with_code (target, preCode, postCode, *args) </code>

* <code>wrap_classes (aspect, pre, post, classes, *methods)</code> - More flexible yet experimental version of the <code>wrap<code> method to wrap methods in multiple classes. Caller must provide the aspect object and regular expression used to match target classes. The rest of the parameters are the same as the <code>wrap</code> method. Note that this API is likely to change in future versions of AspectR.

* <code>add_advice (target, joinpoint, method, advice)</code> - Allows you to specify an advice method to be called when the joinpoint is reached in the specified target class and method. Joinpoint must be either <code>PRE</code> or <code>POST</code>.

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on an instance of the aspect class (any instance).

* <code>dispatch?</code> - Indicates if dispatching to advice methods is enabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> -

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T14:57:17Z

Mwroda: /* Methods */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods for wrapping ===

* <code>wrap (target, pre, post, *args)</code> - Instance method of the aspect class which allows you to specify an advice method in the aspect class to be invoked before and after each intercepted method, along with the target class and an <code>*args</code> parameter which may contain the methods in the target class to intercept, or a regular expression to match method names in the target class.

* <code>unwrap (target, pre, post, *args)</code> - Undoes a wrapping made with the previous method.

* <code>wrap_with_code (target, preCode, postCode, *args) </code>

* <code>wrap_classes (aspect, pre, post, classes, *methods)</code> - More flexible yet experimental version of the <code>wrap<code> method to wrap methods in multiple classes. Caller must provide the aspect object and regular expression used to match target classes. The rest of the parameters are the same as the <code>wrap</code> method. Note that this API is likely to change in future versions of AspectR.

* <code>add_advice (target, joinpoint, method, advice)</code> - Allows you to specify an advice method to be called when the joinpoint is reached in the specified target class and method. Joinpoint must be either <code>PRE</code> or <code>POST</code>.

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

=== Methods for controlling dispatching ===

* <code>disable_advice_dispatching</code> - Disables all dispatching to advice methods by the API. Provided as an instance method so must be called on [any] aspect instance

* <code>dispatch?</code> - Returns true if dispatching to advice methods is enabled, false if disabled.

=== Specifying methods that should never be wrapped ===

* <code>new (never_wrap = "^$ ")</code> -

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

=== Other utility methods ===

The following methods are used by the API itself but also made public:

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T14:46:07Z

Mwroda:

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR API ==

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods ===

The following instance methods are inherited from the Aspect class.

* <code>wrap (target, pre, post, *args)</code> - This is the main utility method which allows you to specify an advice method in the aspect class to be invoked before and after each intercepted method, along with the target class and an <code>*args</code> parameter which may contain the methods in the target class to intercept, or a regular expression to match method names in the target class.

* <code>unwrap (target, pre, post, *args)</code> - Undoes a wrapping made with the previous method.

* <code>wrap_with_code (target, preCode, postCode, *args) </code>

* <code>wrappable? (method)</code> - Indicates if the specified method can be wrapped. See [new] below.

* <code>add_advice (target, joinpoint, method, advice)</code> - Allows you to specify an advice method to be called when the joinpoint is reached in the specified target class and method. Joinpoint must be either <code>PRE</code> or <code>POST</code>.

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

* <code>disable_advice_dispatching</code> - Disables all dispatching of advice methods in the program.

* <code>get_methods (targret, args)</code>

* <code>prepare (target)</code>

The following class methods are inherited from the Aspect class:

* <code>new (never_wrap = "^$ ")</code> -

* <code>dispatch?</code> - Returns true if dispatching to advice methods is enabled, false if disabled.

The following utility methods are provided by the AspectR library:

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

* <code>wrap_classes (aspect, pre, post, classes, *methods)</code> - More flexible yet experimental version of the <code>wrap<code> method to wrap methods in multiple classes. Caller must provide the aspect object and regular expression used to match target classes. The rest of the parameters are the same as the <code>wrap</code> method. Note that this API is likely to change in future versions of AspectR.

== Example ==

The following code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T14:42:18Z

Mwroda: /* Defining Aspects and wrapping methods */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR ==

=== Defining Aspects and wrapping methods ===

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

=== Methods ===

The following instance methods are inherited from the Aspect class.

* <code>wrap (target, pre, post, *args)</code> - This is the main utility method which allows you to specify an advice method in the aspect class to be invoked before and after each intercepted method, along with the target class and an <code>*args</code> parameter which may contain the methods in the target class to intercept, or a regular expression to match method names in the target class.

* <code>unwrap (target, pre, post, *args)</code> - Undoes a wrapping made with the previous method.

* <code>add_advice (target, joinpoint, method, advice)</code> - Allows you to specify an advice method to be called when the joinpoint is reached in the specified target class and method. Joinpoint must be either <code>PRE</code> or <code>POST</code>.

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

* <code>disable_advice_dispatching</code> - Disables all dispatching of advice methods in the program.

* get_methods (AspectR::Aspect)

* prepare (AspectR::Aspect)

* wrap_with_code (AspectR::Aspect)

* wrappable? (AspectR::Aspect)

The following class methods are inherited from the Aspect class:

* <code>new (never_wrap = "^$ ")</code> -

* <code>dispatch?</code> - Returns true if dispatching to advice methods is enabled, false if disabled.

The following utility methods are provided by the AspectR library:

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

* <code>wrap_classes (aspect, pre, post, classes, *methods)</code> - More flexible yet experimental version of the <code>wrap<code> method to wrap methods in multiple classes. Caller must provide the aspect object and regular expression used to match target classes. The rest of the parameters are the same as the <code>wrap</code> method. Note that this API is likely to change in future versions of AspectR.

Wraps methods in one or more classes whose class name matches a regular expression. Unlike the
Caller specifies the aspect class and methods to call before and after each method invocation. A regular expression is used to match on target class names, and either the target methods can be provided or a regu

Specifies an aspect class and advice methods to call before and after method invocations in one or more target classes and methods. The target classes are speci

== Example ==

The code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T14:40:47Z

Mwroda: /* Methods */

= Aspect-oriented programming and AspectR =

AspectR is a very useful Ruby module, but it is not easy to find documentation on it that is appropriate for students taking this class. Find, or construct, documentation that explains what it does without presuming previous knowledge of AspectJ, that describes many or all methods of the module and how they work. Also find or produce an easy-to-understand example that does not involve logging. Show how the example would be implemented in AspectJ and AspectR.

== Overview ==

== Motivation ==

== AspectR ==

=== Defining Aspects and wrapping methods ===

AspectR provides a simple mechanism for wrapping methods in a program. One begins by creating an "aspect" class that inherits from the AspectR Aspect class. You then define the wrapper methods which will be called at the join points in the program. These methods are called Advice methods. AspectR currently supports only two method join points, <code>PRE</code> and <code>POST</code>. The inherited instance method <code>wrap</code> is then used to specify the wrapper methods to be called before and after a method invocation, along with the target class and methods to be intercepted.

<code>wrap (target, pre, post, *args)</code> takes the following parameters:

* <code>target</code> - The target class
* <code>pre</code> - Wrapper method to call before an intercepted method call
* <code>post</code> - Wrapper method to call after an intercepted method call
* <code>*args</code> - Methods from the target class, or a regular expression matching method names from the target class, to be intercepted

=== Methods ===

The following instance methods are inherited from the Aspect class.

* <code>wrap (target, pre, post, *args)</code> - This is the main utility method which allows you to specify an advice method in the aspect class to be invoked before and after each intercepted method, along with the target class and an <code>*args</code> parameter which may contain the methods in the target class to intercept, or a regular expression to match method names in the target class.

* <code>unwrap (target, pre, post, *args)</code> - Undoes a wrapping made with the previous method.

* <code>add_advice (target, joinpoint, method, advice)</code> - Allows you to specify an advice method to be called when the joinpoint is reached in the specified target class and method. Joinpoint must be either <code>PRE</code> or <code>POST</code>.

* <code>remove_advice (target, joinpoint, method, advice)</code> - Removes an advice made with the <code>add_advice</code> method.

* <code>disable_advice_dispatching</code> - Disables all dispatching of advice methods in the program.

* get_methods (AspectR::Aspect)

* prepare (AspectR::Aspect)

* wrap_with_code (AspectR::Aspect)

* wrappable? (AspectR::Aspect)

The following class methods are inherited from the Aspect class:

* <code>new (never_wrap = "^$ ")</code> -

* <code>dispatch?</code> - Returns true if dispatching to advice methods is enabled, false if disabled.

The following utility methods are provided by the AspectR library:

* <code>all_classes (regexp = /^.+$/)</code> - Returns all classes whose class name matches a given regular expression.

* <code>wrap_classes (aspect, pre, post, classes, *methods)</code> - More flexible yet experimental version of the <code>wrap<code> method to wrap methods in multiple classes. Caller must provide the aspect object and regular expression used to match target classes. The rest of the parameters are the same as the <code>wrap</code> method. Note that this API is likely to change in future versions of AspectR.

Wraps methods in one or more classes whose class name matches a regular expression. Unlike the
Caller specifies the aspect class and methods to call before and after each method invocation. A regular expression is used to match on target class names, and either the target methods can be provided or a regu

Specifies an aspect class and advice methods to call before and after method invocations in one or more target classes and methods. The target classes are speci

== Example ==

The code examples implement a code [http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29 profiler] to measure the duration of method calls.

=== AspectR ===

require aspectr.rb
include AspectR

class Profiler < Aspect
def method_start(method, object, exitstatus, *args)
@begin = Time.now
end
def method_end(method, object, exitstatus, *args)
timeElapsed = Time.now - @begin
puts "#{object.class}.#{method} took #{timeElapsed} secs"
end
end

#if $0 == __FILE__
class SomeClass
def some_method
puts "hello"
sleep 5
end
end

Profiler.new.wrap(SomeClass, :method_start, :method_end, /some/)
SomeClass.new.some_method
#end

=== AspectJ ===

== References ==

== External Links ==

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T14:12:34Z

Mwroda: /* Other methods */

CSC/ECE 517 Fall 2010/ch3 3d mr

2010-10-05T14:08:10Z

Mwroda: /* Defining Aspects and wrapping methods */