One of the things I like about groovy is the fact that it interacts so well with Java. There are a couple of reasons that I really like this. 1. I'm coming from nothing but Java ( and a little Cobol ) over the past few years so it is really easy for me to transition to the new syntax. 2. We built a base class "application" that we utilize to drive all of our batch processing stuff, since Groovy can work with Java so well I can write an "application" class that extends this base application and still take advantage of all the functionality that we have already built.
I went the Thorough Introduction to Groovy talk even though I had written some Groovy before, it was all self taught so I saw this as a good opportunity to find out if I was doing it "right". I was happy to find out that I am definitely on the right track. I never knew about the Builders before, but I sure wish that I had because I wrote a whole lot of Java code to mimic that kind of simplicity for a project last year. Of course its not at all the same, because Groovy uses some meta programming to capture method calls to methods that don't exist to get the Job done, but I think my solution makes writing XML just as easy as the Builder does. Of course the big drawback is that I spent a few months writing the code and I can almost guarantee there are at least a few bugs in it because we just made it work for exactly our use case. The other thing in the intro that I wish I would have known about earlier is the Groovy Console. That is really handy for playing around with the syntax to figure out how to do things. I had previously kinda knew what Groovy Properties were, but since I never used them before I did not realize how powerful they could be in respect to less coding, and more importantly the ability to call constructors with a map of what properties you want set. I can't count the number of times I wish a particular domain object had a constructor with a given set of parameters when I was building my unit tests. One thing that I really wish more "intro" class/talks/websites would do different, and this one fell into the same trap but with a warning up front, is that closers are too often associated with loops. Jeff did go through a few other examples like the number.times method that accepts, but that can be done in Java with a for loop. I really like closures in that you can write more concise/cleaner code with them, but I'm still searching for a good example of something that would be just outright painful, or better yet impossible, to do in Java that a closure can do easily. Thinking about them it just feels like that example must be out there. There was just enough of a hint at Meta Programming here to get me to come back to the Meta Programming class later on, so I'll talk more about Meta programming with that class.
Meta Programming is Awesome. Jeff Brown gave a pretty cool talk on this stuff. This is one of those topics that I really never heard of and was totally blown away by how useful it is. It allows you to intercept any method call that you want to ( like AOP ) and do stuff. The big thing that standard AOP doesn't let you do is you can call methods that doen't exist and use Meta Programming to do something useful. The best example Jeff gave was the XML MarkupBuilder. Also using Closures to to add functionality to classes, as well as the more traditional MetaClass way of adding functionality to classes.
No comments:
Post a Comment