Anonymous user
Talk:Aspect oriented programming: Difference between revisions
no edit summary
(Apologies, motivation, suggestions) |
No edit summary |
||
Line 18:
: You are completely right. How about a concrete task: ``Two classes are given, Subject and Observer which contain methods for adding observers to a subject (addObserver, removeObserver), and for propagating a state change in a subject among observers (stateChange on a Subject triggers update on all Observers). Furthermore, there are two classes Temperature and Sensor which do not implement/inherit these roles at all.a a A Temperature just has getTemp and setTemp methods, and a Sensor just has a setTempSource (observe a particular Temperature object), and a sampleTemp method (take the temperature of the Temperature object using getTemp). Using Aspect Oriented Programming (AOP), we can force the Temperature and Sensor classes to implement the Subject and Observer roles, without changing the definitions of these data types or adding code to them. These extensions of behavior are not visible outside of the the aspect module. Outside of the aspect, it appears that sampleTemp is "magically" called on a Sensor whenever the Temperature which it is observing is updated via its setTemp, and neither object has any extra state, and neither class inherit from Subject or Observer. Furthermore, the Subject-Observer aspect is not specific to Sensor and Temperature, but is split into two parts: an reusable abstract Subject-Observer aspect, and the concrete one which specializes to Sensor and Temperature. Use the best approximation of Aspect Oriented Programming (AOP) in your chosen language to reproduce this concept.''[[Special:Contributions/192.139.122.42|192.139.122.42]] 23:56, 14 October 2011 (UTC)
== Apologies, Motivation, Suggestions ==
Sorry for not following the process. I may have mis-labeled the article. I wanted to discuss ways to build up code out of optional pieces which toggle various features/forks of the core software, and I chose to call them aspects. In C this is often done with #define. In Java it can be done by extending classes and overwriting their methods, to make a new fork, or in a more generalised way using AspectJ. It can also be done in many languages using patches from the history. In dyanmic languages like Javascript the addition of new features to the software might be performed at runtime, for example by overwriting exposed functions with enhancing wrappers. Please feel free to rewrite and reuse any parts of the article or destroy it as you see fit. Perhaps it should be renamed "Build Configuration" or "Optional Code" or "Feature Tree". -- OP▼
▲Sorry for not following the process. I may have mis-labeled the article. I wanted to discuss ways to build up code out of optional pieces which toggle various features/forks of the core software, and I chose to call them aspects. In C this is often done with #define. In Java it can be done by extending classes and overwriting their methods, to make a new fork, or in a more generalised way using AspectJ. It can also be done in many languages using patches from the history. In dyanmic languages like Javascript the addition of new features to the software might be performed at runtime,
Task: Write some code which provides an optional feature which may be enabled or disabled as the developer desires, at as high a level as possible in the language. The task could be to write a factorial function which logs each iteration it takes only when the LOGGING feature is enabled.
Output of factorial(3) when LOGGING is enabled:
3 x 2!
2 x 1!
A *modular* answer for Javascript might be:
<lang javascript>
###LOGGING.js###
// Overwrite existing factorial function with a logging version
var oldFactorial = this.factorial;
this.factorial = function(n){
console.log(n+" x "+(n-1)+"!");
return oldFactorial.call(arguments);
};
// Note that this could be modified into a general decorator to add logging to any given function.
function addLoggingTo(parent,name) {
var oldFn = param[name];
param[name] = function(){ console.log(name+" is being called with "+arguments); return oldFn.apply(this,arguments); };
}
addLoggingTo(this,"factorial");
}}
</lang>
This might be considered preferable to #ifdefs which gets mixed into the code. The aspect is separate from the original source.
Some general fallbacks exist for a wide range of languages which have no higher-level support. A simple if (LOGGING) check should always work. Some applications mutate existing code at runtime using a plugin or module framework, in which case the LOGGING feature could be a plugin that may or may not be present to consume log events.
-- OP,--[[Special:Contributions/82.32.24.201|82.32.24.201]] 05:11, 19 October 2011 (UTC)
| |||