CSC/ECE 517 Fall 2007/wiki1b 5 b4: Difference between revisions
Line 91: | Line 91: | ||
</ol> | </ol> | ||
Following is a description of the | Following is a description of all of the methods found in Aspect that you might want to use when utilizing AspectR. | ||
===wrap=== | ===wrap=== |
Revision as of 23:35, 1 October 2007
Assignment
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.
Aspect-Oriented Programming and AspectR
AspectR is a Ruby module that allows you to easily and concisely use the Aspect-Oriented Programming (AOP) paradigm in your Ruby applications.
What is Aspect-Oriented Programming?
When designing and developing a software system, you must account for and handle the many concerns of the system. A concern is a requirement of, or action that must be performed by, the system. For example, concerns for a banking system include making deposits, making withdrawals, handling account inquiries, transferring funds between accounts, authenticating and authorizing the user, and synchronizing and logging all transactions. The concerns at the beginning of the list are the primary, or core, concerns of the banking system, and would likely be handled by separate modules or classes. The concerns at the end of the list are secondary, and are required across many of the core modules. For this reason they are referred to in AOP as cross-cutting concerns.
The standard example used to demonstrate the functionality and benefits of AOP involves logging. A well-designed object-oriented system would have a separate class for logging, and that class would be utilized by all other classes in the system that require logging. By creating a separate logging class, the code that actually formats the logged data and writes it to file only needs to be written once. However, the code that invokes the logging module is still repeated and scattered throughout the system. As a result, the core code is less readable, takes longer to develop, and is much more difficult and expensive to maintain. With AOP, you can weave the logging code into the rest of the system without actually modifying all of the other classes that need to use it. This would be done by creating a logging aspect and using special APIs to specify which classes and methods need to be logged. In this way, the logging concern is kept separate from all other concerns in the system.
Other concerns that are good candidates for AOP include security, database transactions, synchronization, and profiling.
Benefits of AOP include:
- Shorter development time and reduced code size.
- More readable and less cluttered code; this makes the system easier to understand and maintain.
- Much easier to add or delete function as needed.
- Different implementations of a cross-cutting concern can be easily swapped. No changes to the core concerns are necessary.
- Increased productivity. Developers can focus on the primary concern and do not need to address the cross-cutting concerns.
What is AspectR?
The Ruby language has certain facilities built in that make AOP possible out-of-the-box, including aliasing, reflection, and metaprogramming. AspectR is a Ruby module that was written by Avi Bryant and Robert Feldt to make AOP in Ruby even easier. With AspectR, you can create aspects that contain methods (known as advice) which will be called before and after certain specified methods are invoked. In other words, your existing class methods can be "wrapped" with other code by using AspectR. See the AspectR RubyDoc section below for more information on how this works.
AspectR is similar to AspectJ, Java's AOP implementation. AspectR lacks many of the features of AspectJ, however, and the two work very differently. AspectJ works as a preprocessor that actually statically adds the advice code to the classes and methods being wrapped, and then passes the new code to a compiler or interpreter. AspectR, on the other hand, aliases the existing methods in the wrapped class and calls the specified advice methods before and/or after the original method is called. For a more thorough description of the differences between AspectR and AspectJ, see Ruby Developer's Guide.
Downloading and Installing AspectR
In order to take advantage of the features of AspectR, you must first download and install it.
- Go to http://aspectr.sourceforge.net/ and download the tarball aspectr-0-3-5.tar.gz.
- Unpack the tarball. If you are on Windows, this can be unzipped using Winzip.
- From the newly created directory aspectr-0-3-5, execute "ruby install.rb".
These steps will place the AspectR module (aspectr.rb) in your Ruby library.
AspectR RubyDoc
To use AspectR, you'll begin by creating a new subclass of AspectR's Aspect class. Let's call it BasicAspect. Then you'll add two methods to BasicAspect, one containing the code that you want to execute before the original method executes and one containing the code that you want to execute after. We'll call the former before_advice and the latter after_advice. Note that you don't need to have both; you can choose to just have before advice or just have after advice.
Your BasicAspect will look something like this:
require 'aspectr' include AspectR class BasicAspect < Aspect def before_advice(method, object, exitstatus, *args) puts "do something before calling the existing method" end def after_advice(method, object, exitstatus, *args) puts "do something after calling the existing method" end end
Now suppose you have a class, ExistingClass, containing a method that you want to wrap.
class ExistingClass def existing_method puts "executing existing method" end end
Finally, you'll need to use the AspectR API to specify that you want to wrap ExistingClass.existing_method with the advice in BasicAspect.
BasicAspect.new.wrap(ExistingClass, :before_advice, :after_advice, :existing_method) ExistingClass.new.existing_method
Executing this code will give the following output:
do something before calling the existing method executing existing method do something after calling the existing method
Under the covers, AspectR is aliasing existing_method with a new name. When existing_method is called, the following occurs:
- before_advice is called
- existing_method is called via the new name
- after_advice is called
Following is a description of all of the methods found in Aspect that you might want to use when utilizing AspectR.
wrap
Arguments: target, pre, post, *args
Adds the advice specified by pre and post to all methods specified in args on the class or object target. To specify more than one method, pass a regular expression to args.
Example:
BasicAspect.new.wrap(MyClass, :before_advice, :after_advice, /method/)
In this case, all calls to methods on MyClass with names containing "method" will be wrapped by calls to before_advice and after_advice.
unwrap
Arguments: target, pre, post, *args
Removes the advice specified by pre and post from all methods specified in args on the class or object target. To specify more than one method, pass a regular expression to args.
Example:
BasicAspect.new.unwrap(MyClass, :before_advice, :after_advice, /method/)
In this case, the advice before_advice and after_advice will no longer be executed when calls to methods on MyClass with names beginning with "method" are made.
wrap_with_code
Arguments: target, preCode, postCode, *args
Wraps the code in preCode and postCode around the methods specified in args on the class or object target. This method results in faster execution than the wrap method and cannot be undone (i.e. there is no unwrap_with_code).
Example:
class SomeClass def method1(str) puts "executing SomeClass.method1 #{str}" end end Aspect.new.wrap_with_code(SomeClass, %q{puts "entering method"}, %q{puts "exiting method"}, /method/) SomeClass.new.method1 "test"
Output:
entering method executing SomeClass.method1 test exiting method
add_advice
Arguments: target, joinpoint, method, advice
Adds the advice specified by advice to the method method on the class or object target. Use a joinpoint of Aspect::PRE if the advice should be executed prior to the base method; otherwise, use Aspect::POST to execute the advice after the base method returns.
Example:
BasicAspect.new.add_advice(MyClass, Aspect::PRE, :method1, :before_advice)
In this case, the advice before_advice will be executed just before the code in MyClass.method1.
remove_advice
Arguments: target, joinpoint, method, advice
Removes the advice specified by advice from the method method on the class or object target. Use the same value for joinpoint that was specified when add_advice was called (Aspect::PRE or Aspect::POST).
Example:
BasicAspect.new.remove_advice(MyClass, Aspect:PRE, :method1, :before_advice)
In this case, the advice before_advice will no longer be executed just before the code in MyClass.method1.
disable_advice_dispatching
This method takes no parameters but does expect a code block. No pre or post advice is called while the specified code block is executing.
Example:
BasicAspect.new.disable_advice_dispatching {MyClass.new.method1}
Example: Profiler Aspect
One common use of AOP is profiling. Profiling refers to the collection of data about the dynamic behavior of a system. It is done to determine a breakdown of where time and memory are being consumed at runtime and make optimizations based on the results. In the example below, which is based off a sample found in make a link -- Ruby Developer's Guide, we create an aspect that will determine the number of (milli)seconds spent in a single method. It is kept very simple to clearly illustrate the functionality of AspectR; a full-featured profiler would need to account for non-serialized and nested method invocations, aggregate the results, etc.
The Profiler class, which inherits Aspect, contains two methods: profiler_enter and profiler_exit. The before advice, profiler_enter, records the time immediately before the method is invoked. The after advice, profiler_exit, records the time immediately after the method exits and prints out the duration of the method invocation.
require 'aspectr' include AspectR class Profiler < Aspect def profiler_enter(method, object, exitstatus, *args) @enter_time = Time.now puts "#{@enter_time.strftime('%Y-%m-%d %X')} #{self.class}##{method}: #{args.inspect}" end def profiler_exit(method, object, exitstatus, *args) @exit_time = Time.now print "#{@exit_time.strftime('%Y-%m-%d %X')} #{self.class}##{method}: exited " if exitstatus.kind_of?(Array) print "normally returning #{exitstatus[0].inspect} " elsif exitstatus == true print "with exception '#{$!}' " else print "normally " end puts "after #{@exit_time.to_f - @enter_time.to_f} seconds" end end
A user of Profiler would need to wrap all methods that she is interested in profiling. The program below uses the Profiler aspect to calculate the amount of time spent in the SomeClass.method1 method call.
class SomeClass def method1(str) puts "entering SomeClass.method1 #{str}" sleep 5.3 puts "exiting SomeClass.method1" end end Profiler.new.wrap(SomeClass, :profiler_enter, :profiler_exit, :method1) SomeClass.new.method1 "test"
This program generates the following output:
2007-09-30 22:05:51 Profiler#method1: ["test"] entering SomeClass.method1 test exiting SomeClass.method1 2007-09-30 22:05:56 Profiler#method1: exited normally returning nil after 5.29699993133545 seconds
You can see from the Profiler output that SomeClass.method1 took approximately 5.3 seconds to execute, as expected.
Note: A profiler for Ruby programs, RbProf, is included in the AspectR distribution.
References
- Aspect-oriented programming from Wikipedia
- AspectJ in Action
- AspectR README
- CSC517 Lecture 08: Reflection and metaprogramming
- Mastering AspectJ
- Ruby Cookbook
- Ruby Developer's Guide
- The Ruby Way