Annotations are a funny thing, you can (like anything) also abuse
them. There's a project out there (don't know if I should point it
out) that decided to create listeners via annotations instead of
listener interfaces.
It actually ends up with the code being less clear than the
alternative.
ex:
public class TrumpetTest implements TrumpetListener{
public void playTrumpet(Event ev) {
}
public Test() {
Trumpet trumpet = new Trumpet ();
trumpet .addTrumpetListener(this);
}
}
vs
@Listener
public class TrumpetTest {
@PlayTrumpet
public void annotatedListen(Event ev) {
}
public Test() {
Trumpet trumpet = new Trumpet ();
trumpet .addListener(this);
}
}
Now the annotation approach makes it so that there are less
addXXXListener() methods, and I can have an uber listener that has a
list of annotations (@PlayTrumpet, @FixTrumpet, etc) but this makes
the code harder to maintain.
The annotation makes it so there's only one method signature for the
events, with a shared event object and also (at least in the API I'm
talking about) you can tag a method with an annotation with different
args, you just don't get the event (or even know about the contract
for the event).
Horrible!
On Oct 25, 6:41 pm, Liam Knox <[email protected]> wrote:
> Yes fantastic metric characters are in measuring bolierplate
>
> i.e
>
> foo() {
> t.s();
>
> t.c();
>
> }
>
> or
>
> @Transactional
> foo(){}
>
> On Mon, Oct 25, 2010 at 10:31 PM, Kevin Wright
> <[email protected]>wrote:
>
>
>
>
>
>
>
> > No, because that's based on an assumption that more lines = more
> > functionality
>
> > Though I can see how those in favour of not removing boilerplate, and
> > questioning the benefits of a 30% reduction might see this as a good metric
>
> > On 25 October 2010 14:28, Liam Knox <[email protected]> wrote:
>
> >> Should we go back to measuring productivity by lines of code written?
>
> >> On Mon, Oct 25, 2010 at 10:26 PM, Augusto Sellhorn <
> >> [email protected]> wrote:
>
> >>> This is really bizarre, I've heard people say that fewer lines of code
> >>> is desirable, but this is the first time I hear somebody say that X%
> >>> fewer characters lead almost exactly to X% reduction in complexity!
>
> >>> ---------------
>
> >>> for(int
> >>> indexOfAuthorInCurrentIteration=0;
> >>> indexOfAuthorInCurrentIteration<=authorsFromNameQuery.length;
> >>> ++indexOfAuthorInCurrentIteration) {
> >>> Author currentAuthorBeingIteratedOver
> >>> = authorsFromNameQuery[indexOfAuthorInCurrentIteration]
> >>> // do something with the author
> >>> }
>
> >>> ---------------
>
> >>> Nobody is saying you have to use super long names here, what you are
> >>> saying is that less characters more % reduction in complexity, which
> >>> leads to this
>
> >>> for (int i=0; i <= aq.length; ++i) {
> >>> Author aa = aq[i];
> >>> // do something with the author
> >>> }
>
> >>> Which I don't think results in any % less chances of bugs, as a matter
> >>> of fact it ends up being less readable than some reasonable and clear
> >>> names that could have been applied.
>
> >>> I hope in your code reviews you are not doing character counts and
> >>> blasting developers on these bogus measurements.
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "The Java Posse" group.
> >>> To post to this group, send email to [email protected].
> >>> To unsubscribe from this group, send email to
> >>> [email protected]<javaposse%2bunsubscr...@googlegroups
> >>> .com>
> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/javaposse?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "The Java Posse" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected]<javaposse%2bunsubscr...@googlegroups
> >> .com>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/javaposse?hl=en.
>
> > --
> > Kevin Wright
>
> > mail / gtalk / msn : [email protected]
> > pulse / skype: kev.lee.wright
> > twitter: @thecoda
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<javaposse%2bunsubscr...@googlegroups
> > .com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
