I have heard about aspects during studies. I was not very interested in it and did not have any need to learn about it more. What I've heard was mainly about 'reusable code' and about 'software patching'.
Software patching was explained to me as a method to make some changes in software not being forced to make changes in sources and compile it again. So, what is the advantage? As you know, after deploying new version of application that someone out-there is using, test team should make everything what is possible to make sure, that the fixes in new version did not brake anything (and did not make any new bugs).
The example describing the technique of 'software-patching' I was given was: lets imagine a big financial system being used by a bank or a financial company. Lets image, that the financial law in a country is being changed, so changes to the system are necessary. Traditional way is to make changes (I mean: write some additional code fixing the way system calculates taxes...) and deliver it to the client. (Of course, there is way better approach - at the stage of analysis someone could have been such a clever person who could predict this situation, and think of it, so decision could have been made not to use fixed tax rates but to store the tax rate into a special 'configuration' table in database, or in config files. But... lets think for a while, that the system we are considering changing was not created in this situation in mind).
So what is the aspect approach? It is based rather on idea of 'plugins' than one-big monolith. So, the idea is to deliver additional code, that will be called before, or after a specified function / procedure, so it may change the behaviour of the whole application. In the example, the code should take the return value from the function that calculates tax, and should add the amount so the height of the tax would be calculated properly.
There are of course some problems in delivering the patches, but... it was just an example ;)
The second approach's goal is rather to help in the stage of creating application, than stage of patching it. It is being used during development. The common situation is that it is more and more complex to split code into proper layers. In business / logic layer there is always some code that is totally technical: exception handling, logging, etc. At the very beginning it may not be a big problem, but when application grows it become more and more significant (. Thanks to aspect oriented approach we may use .NET attrributes and inform the compiler that before/after this specified functions (or bunch of function which names contains specified characters: "OnClick" for example) some additional code (delivered in separate function) should be run.
Sounds like very interesting idea, isn't it?
About the second approach, I have heard recently - last Saturday - to be more precise. I have attended to Gael Frateur's lecture during CodeCamp (held in Krakow). I must admit, that I really enjoyed the presentation, and I think it was really worth attending to and listening. Now I am preparing one of my small projects to benefit from AOP concepts.
Aspect oriented programming is not very widely know or used, but there are surprisingly many solutions for different languages (and platforms) available - so I think anyone interested in it would be able to find something suitable (there are a lot of projects for .NET and Java, there are some for C++ and also for Python and even Lua! - this list seems to be quite comprehensive ).
There are two projects for .NET platform I have read about (and tried to use in very, very simple test projects):
For me, aspect oriented programming is very interesting technique. I am planning to devote more time and investigate the possibilities and limitations of AOP in the nearest future.
Software patching was explained to me as a method to make some changes in software not being forced to make changes in sources and compile it again. So, what is the advantage? As you know, after deploying new version of application that someone out-there is using, test team should make everything what is possible to make sure, that the fixes in new version did not brake anything (and did not make any new bugs).
The example describing the technique of 'software-patching' I was given was: lets imagine a big financial system being used by a bank or a financial company. Lets image, that the financial law in a country is being changed, so changes to the system are necessary. Traditional way is to make changes (I mean: write some additional code fixing the way system calculates taxes...) and deliver it to the client. (Of course, there is way better approach - at the stage of analysis someone could have been such a clever person who could predict this situation, and think of it, so decision could have been made not to use fixed tax rates but to store the tax rate into a special 'configuration' table in database, or in config files. But... lets think for a while, that the system we are considering changing was not created in this situation in mind).
So what is the aspect approach? It is based rather on idea of 'plugins' than one-big monolith. So, the idea is to deliver additional code, that will be called before, or after a specified function / procedure, so it may change the behaviour of the whole application. In the example, the code should take the return value from the function that calculates tax, and should add the amount so the height of the tax would be calculated properly.
There are of course some problems in delivering the patches, but... it was just an example ;)
The second approach's goal is rather to help in the stage of creating application, than stage of patching it. It is being used during development. The common situation is that it is more and more complex to split code into proper layers. In business / logic layer there is always some code that is totally technical: exception handling, logging, etc. At the very beginning it may not be a big problem, but when application grows it become more and more significant (. Thanks to aspect oriented approach we may use .NET attrributes and inform the compiler that before/after this specified functions (or bunch of function which names contains specified characters: "OnClick" for example) some additional code (delivered in separate function) should be run.
Sounds like very interesting idea, isn't it?
About the second approach, I have heard recently - last Saturday - to be more precise. I have attended to Gael Frateur's lecture during CodeCamp (held in Krakow). I must admit, that I really enjoyed the presentation, and I think it was really worth attending to and listening. Now I am preparing one of my small projects to benefit from AOP concepts.
Aspect oriented programming is not very widely know or used, but there are surprisingly many solutions for different languages (and platforms) available - so I think anyone interested in it would be able to find something suitable (there are a lot of projects for .NET and Java, there are some for C++ and also for Python and even Lua! - this list seems to be quite comprehensive ).
There are two projects for .NET platform I have read about (and tried to use in very, very simple test projects):
- LOOM.NET - it has two different weavers: Gripper and Rapier. Gripper is static, and Rapier is dynamic one.
- PostSharp - this solution is based on post-compiler approach, just to cut that short: it is intended for development, not software patching
For me, aspect oriented programming is very interesting technique. I am planning to devote more time and investigate the possibilities and limitations of AOP in the nearest future.
No comments:
Post a Comment