Aspect Oriented Programming

3]) · 2011-04-05 21:14:52

So I was following and reading some programming websites, when I heard that the future is 'aspect oriented', and that it will overtake 'object oriented programming'.

Liking the bleeding edge I immediately searched what the hype was all about.

I landed at: http://en.wikipedia.org/wiki/Aspect-ori … evelopment
and at http://en.wikipedia.org/wiki/Aspect-Ori … rogramming

Here is the definition:

In computing, aspect-oriented programming (AOP) is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns. AOP forms a basis for aspect-oriented software development.

and info

Aspect-oriented programming entails breaking down program logic into distinct parts (so-called concerns, cohesive areas of functionality). All programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program.

From what I understand its all about 'modularity' and unlike functional programming and object oriented programming just a 'style' of doing things, not a 'way to solve problems'.

Hence, although code might be harder to read it will be more stable, as certain functions can't break down the entire program, at least thats my take from this. Testing will also be easier to do.

Yet, do we not all use some aspect of aspect oriented programming?
Especially when commencing in the creation of games or advanced applications where one might use more than one .py-.cpp file, and most often import that file to a main run file?

I might be completely wrong on my stance, or even with my understanding of Aspect Oriented Programming,hence the need for discussion.

Whats your take on this Arch programmers?
Do any of you actually use it?
If so, why, if not, why not?

Last edited by 3]) (2011-04-06 07:10:12)

Fingel · 2011-04-05 21:52:55

The project I develop at work makes heavy use of AspectJ, which is an aspect oriented extension for java. It is useful for placing different class functionality groups in different files. For example you have one file for all of the entity level methods, such as findWidgets(), another class for all your setters and getters, another for tostring()s, etc. This leaves your main widget.java with only main business logic without all the clutter of everything else.
The real power comes when use in conjunction with a rapid development framework. We use roo, which manages all of the .aspectj files. So for example, if I add a new variable "foo" to widget.java, all the aspect files are automatically updated - getters and setters, tostring, etc. You mentioned it makes code harder to read, I disagree. Its actually quite nice to have several smaller functionally sepeaated files than one large class file with all the functionality grouped together.
I wouldn't claim that aspect oriented programming (if Im doing it right) is any different than object oriented programming, its just a way of spitting things up to make it easier for the programmer. All the aspects are "woven" into the main class at a later point anyway so its still just one class/object.

scorpyn · 2011-04-05 22:30:42

I don't get it. They invented a word for splitting code into several files? Or a word for using the same function in more than one place?

Btw, both links in OP are identical. Perhaps one of them should be this : http://en.wikipedia.org/wiki/Aspect-Ori … rogramming

3]) · 2011-04-06 07:28:31

Fingel wrote:

Its actually quite nice to have several smaller functionally sepeaated files than one large class file with all the functionality grouped together.
I wouldn't claim that aspect oriented programming (if Im doing it right) is any different than object oriented programming, its just a way of spitting things up to make it easier for the programmer. All the aspects are "woven" into the main class at a later point anyway so its still just one class/object.

So, by this definition almost all games and applications use some of the aspect oriented programming.

From my understanding now, aspects are a bit like pointers,
except that they can point to specific variables used by specific files
that you are able to more easily use instead of sections in memory.

scorpyn wrote:

I don't get it. They invented a word for splitting code into several files? Or a word for using the same function in more than one place?
Btw, both links in OP are identical. Perhaps one of them should be this : http://en.wikipedia.org/wiki/Aspect-Ori … rogramming

Just fixed the links, thanks for the heads up.

By this definition of yours, in python, you could do

from foo import *

and it would be aspect oriented programming, if I'm correct,and if you have more than two files.

So even importing from a library could be aspect oriented programming?

Image of comparison(normal is one without the aspect file)-http://www.developer.com/img/articles/2 … 05/AOP.gif

This type of programming is looking to be like a patent case, incredibly vague yet incredible in terms of apparent complexity.

I guess it all has to do with the nifty 'aspect' file that differs this from the rest of programming.

Not incredibly minimalists though. Maybe that is why the adoption rate hasn't been as quick as OOP.

Last edited by 3]) (2011-04-07 21:49:28)

scorpyn · 2011-04-06 10:38:59

3]) wrote:

Aspect oriented:http://www.developer.com/img/articles/2 … 05/AOP.gif
Normal: http://www.developer.com/img/articles/2 … 05/AOP.gif

Both of those links are the same...

I though splitting the code into several files was the standard way of doing it? I must be missing something...

3]) · 2011-04-07 21:50:54

scorpyn wrote:

3]) wrote:
Aspect oriented:http://www.developer.com/img/articles/2 … 05/AOP.gif
Normal: http://www.developer.com/img/articles/2 … 05/AOP.gif
Both of those links are the same...
I though splitting the code into several files was the standard way of doing it? I must be missing something...

You split up code, yet you add a special 'aspect' file that links all the code somehow together. The extra step seems to be the 'weaver', which connects all the code together
and then, finally, in the end will result in the compilation of the code. Aspect oriented programming seems to be more time consuming, from what I'm seeing.

Ironically, I thought the author had posted two images to represent each type of programming.
However, both normal and aspect oriented programming are shown in that diagram.

Weaver is the icon tree represented aspect oriented programming, and the other the normal type of programming.

Thanks for the heads up-again.

Last edited by 3]) (2011-04-07 21:52:53)

scorpyn · 2011-04-08 10:47:51

So... I think I get it now...

http://www.developer.com/lang/article.p … amming.htm

I'm sorry, I don't see why this is a good idea. It just looks like you're increasing the code while shuffling the issues in front of you, creating code that will become completely unreadable after a while.

Maybe I'm still missing something.

the_isz · 2011-04-08 11:48:38

The way I understood it, AOP doesn't have directly something to do with
separation of code into files. I'd like to explain it with an example:

Say you have an accounting software and - naturally - a class named Account
which features such functions as deposit and withdraw:

class Account:
  def __init__(self):
    self.__balance = 0

  def deposit(self, amount):
    self.__balance += amount

  def withdraw(self, amount):
    self.__balance -= amount

Now, you can imagine that the deposit and withdraw functions contain a lot more
code than just the simple, single line in the example above. Like connecting to
a server, logging in and out, maybe checking if the account is overdrawn, etc.

The software is running properly, but now you are requested to implement a
logging system, so that every action on an account can be logged. This would
typically include implementing logging code into every function to be logged and
the "aspect" of logging would be distributed to many functions.

Now, the target of AOP is to encapsulate the functionality of one aspect of your
program in one place. In Python, this could be achieved via a decorator:

class Account:
  @Logging
  def __init__(self):
    self.__balance = 0

  @Logging
  def deposit(self, amount):
    self.__balance += amount

  @Logging
  def withdraw(self, amount):
    self.__balance -= amount

Note that the code of the functions hasn't changed, yet we have extended the
class with logging features. This is how I understand AOP.

For the sake of completeness, the logging code might look something like this:

def Logging(function):
  @functools.wraps(function)
  def wrapper(*args, **kwargs):
    print("{} called.".format(function.func_name))
    return function(*args, **kwargs)
  return wrapper

BimoZX · 2011-05-16 03:01:39

So in theory it works like web development? Where it segregate HTML, JS, and CSS and finally
combining it to one file for the browser to read?

But just like 3]) said (at least what I get), it's really like most programming practices nowadays
where they just put a single run file to aggregate all the components for the software.

It seems to just add more work, coming from an amateur ruby programmer though.

the_isz · 2011-05-16 06:34:11

BimoZX wrote:

So in theory it works like web development? Where it segregate HTML, JS, and CSS and finally
combining it to one file for the browser to read?
But just like 3]) said (at least what I get), it's really like most programming practices nowadays
where they just put a single run file to aggregate all the components for the software.
It seems to just add more work, coming from an amateur ruby programmer though.

Read my post above. I'm pretty sure that's much closer to what AOP is than just
separation of code into files.

akb825 · 2011-05-16 08:02:44

This is done very often when refactoring code: take out common code used in multiple systems into a separate module to be used by all. It's just a fancy name for "good design", and the opposite of spaghetti code. (ravioli code?)

I really dislike purists for programming styles. A lot of people think that object oriented, imperative, functional, or (apparently now) aspect oriented (even though that doesn't really seem like a paradigm...) is the "one true way" to code. While most of my code is object oriented, I believe to write good code you should have a combination of multiple paradigms where it makes sense. Each paradigm has its strengths and weaknesses, so why not use each of those where it makes sense? That's why I like multi-paradigm languages such as C++, or better yet, D.

Last edited by akb825 (2011-05-16 08:07:45)

the_isz · 2011-05-16 08:23:31

akb825,

you are right that encapsulating code is common to all programming paradigms.
The difference merely lies in the "container".

In functional programming, algorithms are stored in functions and data (mostly
function references) are stored in lists. Object-oriented code mostly stores
states in objects and defines functions to modify/use these objects.
Aspect-oriented algorithms modify existing ones to augment them with new
functionality. Those algorithms can be defined in a functional way (as in my
example above) or in and object-oriented one.

I'm absolutely with you on the multi-paradigm coding. One needs to find the
right tool for the right job and for that, one shouldn't restrict oneself to a
specific paradigm. In that, aspect-orientation is just one more tool at the
programmer's hands.

BimoZX · 2011-05-16 08:49:01

Correct me if I'm wrong,

So basically AOP takes a step further in encapsulating each modules/objects, and in a case
where a generic function is needed, you basically make it in one file/class, and reiterate them
when needed in other, without disrupting or breaking the general flow of the program.

Am I heading in the right direction?

the_isz · 2011-05-16 09:06:08

BimoZX wrote:

Correct me if I'm wrong,
So basically AOP takes a step further in encapsulating each modules/objects, and in a case
where a generic function is needed, you basically make it in one file/class, and reiterate them
when needed in other, without disrupting or breaking the general flow of the program.
Am I heading in the right direction?

Sounds about right, maybe a bit too complicated It's basically attaching a
function to another instead of calling a function from another. It doesn't
interfere with the original code as much and keeps one aspect ("Logging" in my
example above) in one place.

Just google around a bit, I'm sure you'll find more (and most probably better)
examples for that around. Python is a good language to look at because its
builtin decorators allow for AOP design.

BimoZX · 2011-05-16 09:21:54

Oh I get it, so the class takes the function likes its own rather than taking it as an alien class.

It reminds more about CSS in SASS though, then again it's not really a programming language
per say.

Thanks for the enlightenment, much appreciated. Gotta brush up on my OOP skills first though.

Arch Linux

#1 2011-04-05 21:14:52

Aspect Oriented Programming

#2 2011-04-05 21:52:55

Re: Aspect Oriented Programming

#3 2011-04-05 22:30:42

Re: Aspect Oriented Programming

#4 2011-04-06 07:28:31

Re: Aspect Oriented Programming

#5 2011-04-06 10:38:59

Re: Aspect Oriented Programming

#6 2011-04-07 21:50:54

Re: Aspect Oriented Programming

#7 2011-04-08 10:47:51

Re: Aspect Oriented Programming

#8 2011-04-08 11:48:38

Re: Aspect Oriented Programming

#9 2011-05-16 03:01:39

Re: Aspect Oriented Programming

#10 2011-05-16 06:34:11

Re: Aspect Oriented Programming

#11 2011-05-16 08:02:44

Re: Aspect Oriented Programming

#12 2011-05-16 08:23:31

Re: Aspect Oriented Programming

#13 2011-05-16 08:49:01

Re: Aspect Oriented Programming

#14 2011-05-16 09:06:08

Re: Aspect Oriented Programming

#15 2011-05-16 09:21:54

Re: Aspect Oriented Programming

Board footer