Simon Wacker

I’m now starting to blog in german too. Kai König asked me to do this to strengthen the german blog community. I think of it as a good idea and will thus take the burden on me and translate all following posts from english to german or vice versa. The german blog will be available under the following link: www.simonwacker.com/blog/german. I hope it will be worth its effort.

In the AOP examples I used in my previous posts I always captured exactly one join point with my pointcut. If you would always do it that way you had to define one pointcut for every join point. That is as you can probably imagine not effective. The real benefit comes then when you capture join points due to specific characteristics. For example you wanna capture every method in a specific class that throws an Exception. To do this you need wildcards.
AspectJ offers three wildcard notations:

- “+” indicates all subclasses or subinterfaces of a given type
- “..” indicates any number of charecters including all periods
- “*” indicates any number of characters excluding the period

You also have the negation operator “!” and the two operators “||” and “&&”.

Example:
public pointcut myPointcut() : execution(public * javax..*Model+.set*(*));

This would capture the execution of all public methods starting with set, taking one argument of any type, regardless of the return type that are defined in a class whose name ends with Model or any of its subclasses that reside in the javax package or any direct and indirect subpackages.

Funny … isn’t it?

I was shocked when I read in a forum on Flash from a developer I really admire that he has never used interfaces as type definitions. He even asked if that really works. I just thought: “Huh! What’s going on?” Thus here a few thinks I learned about interfaces:

The Key Sentence:
Program to interfaces rather concrete implementations.

That’s the sentence you should always keep at the back of your mind while programming. Following this golden rule offers the following advantages:

1. Loose coupling between objects which promotes flexibility. You are not bound to concrete implementations. Thus you can change them easily when you have to without affecting calling code.
2. You can write simple stub implementations to ease the testing of classes. It also enables teams to work in parallel after they have agreed on interfaces.

Interfaces in Flash are sadly not that mature yet. There are a few problems related to working with them in practice. Martin and me came across them during the early days of the as2lib. He has summed them up in two posts on the as2lib blog: Interface Mistakes by Macromedia and :Object is Evil. But even with this limitations you should nevertheless work with interfaces because the advantages much outweigh the problems of them in Flash.
Read on to see interfaces in action.
(more…)

I covered the basics of AOP in my previous articles “AOP - Aspect Oriented Programming” and “AOP: Terms and AspectJ”. If you haven’t read them yet I’d suggest you to do this now. Otherwise just go on reading.
As I mentioned earlier pointcuts capture or identify join points. Named poincuts have the following syntax:

Syntax:
[access-specifier] pointcut pointcut-name([arguments]) : pointcut-type(signature)

Example:
public pointcut myPointcut() : execution(public void MyClass.myMethod())

You do use them in an advice as follows:

before() : myPointcut() {
…
}

Anonymous pointcuts are directly declared behind the “:”. It would then look like this:

before() : execution(public void MyClass.myMethod()) {
…
}

Well, that’s it for now. Easy, isn’t it? I will cover wildcards in my next article about AOP. And I hope that at the latest then you will recognize that AOP is a lot of fun.

I’m currently documenting all classes of the as2lib. Good documentation is often neglected in the world of ActionScript. Although it is very important. Thus here a few guidelines.

Why should I document code?
It’s quite easy to answer this question. Others too wanna know what’s going on or how they can use the code. And that without rummaging through all the stuff. But it’s also a help for you. Imagine you write a piece of code and years later you need to use it. You probably don’t know anymore how to work with it. And without good documentation you had to spend maybe an hour to just get the whole thing to work.

How do I document?
There exist a few standards. These standards are actually from a Java background but you can use them in every language. It’s important to pay attention which standards you documentation tool uses to extract the documentation properly.
The follwing link may be useful: http://java.sun.com/j2se/javadoc/writingdoccomments/.
Let’s start:

The Basic Construct:
/**
*
*/
That’s the basic construct. You probably know it. Just use it for every doc comment.

Block Tags:
Block tags are tags preceded by an @. The one you do probably need at most are: @param, @return, @see, @throws, @author and @version. There do exist more. You can find them with a big description under the link I posted above.

How a Doc Comment is Made Up:
/**
* [description]
*
* [block tags]
*/

Example:
I’ll just use the example from the above link because it is (almost) perfect:

I’m sorry for the bad design (no spaces etc.) but MovableType screws the whole thing up. If you know how to fix it let me know.
[Edit]The spaces work now. At least in the example.[/Edit]