In the Spotlight - Andrew Glover

• Web Component Testing Screencast- my friend Rod Coffin demonstrates some interesting aspects related to efficient web testing.
• Software Is Deployed, Bugs and All- does this surprise you?
• % test coverage doesn’t provide useful information- you are correct, man; in fact, code coverage is only effective at telling you what you haven’t tested.
• Java Performance Tuning: A Conversation With Java Champion Kirk Pepperdine- great quote: “Complex code tends to confuse [just-in-time compilers], so that they provide either suboptimal optimizations or no optimizations at all.” Oh yeah, not to mention complex code is a bear to maintain!
• Minimalist Coding Style- now, what would Kirk say regarding this style of coding?
• Unstable code- speaking of code, Oren’s got a brain teaser here, although “unstable” is quite a generic term and thus, might have lead to the number of different comments he received.

The copasetic virtues of easyb have made there way to New Zealand and will be discussed during the Java Emerging Technologies Conference 2008 in Auckland on September 17th. My friend and über Java technologist, John Ferguson Smart will be chewing the fat over easyb and as he states:

The talk will be very practical…There will also be some live demos just to prove that it really is as easy as it looks!

Needless to say, man, having John, who also happens to have authored the veritable bible of all things related to high speed Java development (also known as Oreilly’s Java Power Tools), talk about easyb is great news! In fact, if you didn’t already see it, John also blogged about easyb in which he aptly pointed out that BDD enables you to think

about what your class “should” do– in other words, you are thinking specifications. The difference is subtle, but this turns out to be a much more intuitive way of driving development than thinking in terms of raw tests. Rather than saying “what do I test”, you are saying “what should my class actually do”, or “how should my class behave”. Which is very much the spirit behind TDD.

Well said, baby! If you are hip enough to be located anywhere near New Zealand, you should definitely plan on attending JET and while you are at it, join the party baby and check out easyb.

I recently found myself needing to add additional hip behavior to an object that handled feed parsing– i.e. I needed to add a series of filters (such as location and price) to the items being obtained from the feed. Of course, the easiest (and probably the most naive) way to achieve such a goal is to have added a few conditionals to the feed parsing object itself; however, I realized that this particular problem already had an answer to it– the decorator pattern.

A copasetic example of the decorator pattern in use is Java’s IO library– for example, in the Java code below, a FileReader instance is decorated by a BufferedReader instance.

BufferedReader br = new BufferedReader(new FileReader("readme.txt"));

As my friend, David Geary, wrote many years ago, decorating objects, such as with a BufferedReader, essentially forwards

method calls to the objects they decorate…Decorators add functionality either before or after forwarding to the object they decorate..

So in the code above, decorating the FileReader instance with a BufferedReader facilitates “buffering characters so as to provide for the efficient reading of characters” while reading a file.

One key aspect of the decorator pattern, baby, is a reliance on polymorphism; consequently, in normal Java, for example, the decorator object must implement the same interface (or extend some base class) as the object it intends to decorate; consequently,

the Decorator is indistinguishable from the [hip] object that it contains. That is, a Decorator is a concrete instance of the abstract class, and thus is indistinguishable from any other concrete instance, including other decorators. This can be used to great advantage, as you can recursively nest decorators without any other objects being able to tell the difference, allowing a near infinite amount of customization.

Indeed, the indistinguishable nature of objects facilitated via polymorphism is fundamental to a cornucopia of patterns. And with Groovy, polymorphic behavior can be achieved more easily; that is, patterns that rely on polymorphism can be realized without class hierarchies.

For instance, the original object that required additional behavior is a normal class defined in Groovy:

class FeedReader {

 def readFeed(interestItem, feed, lastUpdateTime) {
  def input = new SyndFeedInput()
  def mefeed = input.build(new XmlReader(feed.toURL()))
  def lstdate = mefeed.entries[0].publishedDate as Date

  def feeditems = []

  if (lstdate.after(lastUpdateTime)) {
    mefeed.entries.each { entry ->
     if (entry.publishedDate.after(lastUpdateTime)) {
      feeditems << new FeedItem(item: interestItem,
        title: entry.title, link: entry.link,
        description: entry.description.value,
        publishedDate: entry.publishedDate)
      }
    }
   }
  return feeditems
 }
}

This class defines one method, readFeed, that reads an RSS/Atom feed using ROME and every item added since the last time the feed was parsed is added to a collection and consequently returned to the caller. As I noted earlier, one could simply add another set of conditionals to the closure to check for, say, the price and location of an item before adding it to the collection; however, a more extensible solution is to apply the decorator pattern and thus decorate the FeedReader.

For instance, in the case of filtering on the price of an item (which, by the way, is dynamically determined based upon the entry’s title), all I had to do was to create a new trippin’ class, in Groovy, that merely contains a method with the same signature:

class PriceFilter {
 private def feedReader
 private int maxPrice

 public PriceFilter(feedRdr, price) {
   this.feedReader = feedRdr
   this.maxPrice = price
 }

 def readFeed(interestItem, feed, lastUpdateTime) {
   def items = this.feedReader.readFeed(interestItem, feed, lastUpdateTime)
   def filteredItems = []
   items.each {item ->
    int iprice = item.getPrice().toInteger()
     if (iprice <= this.maxPrice) {
      filteredItems << item
     }
    }
  return filteredItems
 }
}

Note how the PriceFilter class also has a readFeed method and that that method first defers to an instance, such as FeedReader, and then decorates the result– that is, the PriceFilter class checks each object returned and compares prices. Note too, that I’ve defined a constructor that takes an instance of some object that ideally has a readFeed method– this object isn’t tied to a FeedReader or an interface– it is only tied via the method contract.

Groovy purists will probably bark at me for defining a constructor– indeed, had I dropped the private moniker on the class’s instance variables, a constructor would have been generated for me. In this case, because it’s my bag, old habits never die and I purposely made those instance variables private and thus am forcing clients to properly initialize the object for proper usage.

As you can see, Groovy’s dynamic typing permits me to arbitrarily decorate objects– all that I need to do is ensure decorators have the same method. Then by leveraging constructors, one can easily chain instances like so:

def priceFilter = new PriceFilter(new LocationFilter(mock, locs), 20)

In the code aboe, two filters are applied to the original FeedReader, which, in this case, is actually a mock object that simply has a readFeed method! By the way, this sort of sans-interface polymorphism isn’t limited to Groovy only– the original FeedReader class could have easily been defined in normal Java. Plus, this sort of voodoo polymorphicness can be easily achieved in Ruby, JRuby, Python, and Jython to name a few.

Groovy definitely makes it easier to implement fundamental design patterns by enabling you to leave out the standard scaffolding; what’s more, ubiquitous polymorphism via signatures rather than hierarchies makes testing a whole lot easier! Think about it for a second– my FeedReader instance requires a feed to parse! But I can almost effortlessly mock it by creating an object that responds to a readFeed method. That’s it! Is that smokin’ or what, baby?

Enjoy the hip links, baby:

• CM Crossroads on SCM for Small Teams- configuration management tips are always helpful reading, man.
• JSR 326 - Post mortem JVM Diagnostics API- interesting stuff, indeed.
• JBehave 2.0 in progress- 2.0 is making its way out to the world– should be interesting to check it out.
• Tim Bray slams SOAP … and Java- REST is the future, baby!
• Community Restlet tutorials- speaking of REST, there are a lot of resources out there!
• The Code Reuse Myth- interesting take on this one.

Representational state transfer (also known as REST, baby) is an approach to designing loosely coupled applications that rely on named resources rather than messages. As it turns out, the most involved part of building a RESTful application is deciding on the resources you want to expose. Once you’ve done that, building RESTful Web services a snap, especially if you use the Restlet framework, which greatly simplifies the task of defining and implementing RESTful services.

Check out IBM developerWorks‘ tutorial dubbed “Build a RESTful Web service“– in it, you’ll get to know what REST is and how to build RESTful applications with Restlets, plus, you’ll see how to deploy and test them while you are at it!