I think annotations and interfaces have to be looked at as different, which obviously they are, but with some overlap in functional context. If you really want some object to have a concrete and binding function which must be obeyed by all then interfaces give you that. Annotations however give you more flexibility to decorate and define use case. Classic is JUnit where you want to define what methods are Testable and can also extend to define what exceptions are expected.
On Wed, Oct 27, 2010 at 8:36 AM, Augusto Sellhorn < [email protected]> wrote: > 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%[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%[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%[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%[email protected]> > . > 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.
