Creating prototype Spring beans on demand using lookup-method

The strength of the Spring Framework is its emphasis on stateless services. Being totally against OOP, this approach has many pragmatic advantages, with low memory consumption, no cost of pooling and multithreaded safety at the top of the list. But sometimes you really need the context and having non-singleton beans with different state attached to each instance makes your code a lot cleaner and easier to read. Let’s start from stateless code and do some consecutive refactorings.

Every time a new flight is entered into the system, we validate it with multiple business rules using FlightValidator class (please forgive my complete absence of domain knowledge):

public class FlightValidator {

@Resource
//Many services

public boolean validate(Flight flight) {
return validateSourceAndTarget(flight) &&
isAirplaneAvailable(flight) &&
isAirportFree(flight) &&
!buyerBlackListed(flight) &&
reservationLimitReached(flight);
}

//Many more methods

}

There is something really disturbing in this code. The context (Flight instance being validated) is passed over and over through subsequent method invocations. On the other hand, because the context exists on the stack (which is thread local in the contrary to the heap), the class is thread safe by its definition. But still the code is so awkward that having flight field accessible to every method in the class (and sacrificing thread safety) is very tempting*. The easiest solution is to have a new, separate instance of FlightValidator every time we need to validate a flight. So we create FlightValidator bean with prototype scope:

Few words after Javarsovia 2010

It is never too late to mention about such a great event like Javarsovia 2010 conference. The conference was really successful, even though I was one of the speakers ;-). If you were near Warsaw on 26th of June and missed the conference I feel really sorry for you. But first things first.

I was really surprised not seeing long queues for the registration, so not wasting a lot of time, equipped with good-looking conference T-shirt, we went to see the first presentation. Tomasz Bujok with his From zero to jBPM hero! lecture did a great job introducing jBPM framework. I have seen quite a few presentations about this engine already, thankfully Tomasz made one step further in the topic and have shown some anti-patterns and other tips for jBPM developers. This was really interesting as anyone, after reading a book or two, can have a "How-to" talk. But having "How-not-to" talk requires knowledge and experience in the technology far beyond the typical tutorial-driven "experts". I would really like to work with jBPM for a while, but I’m also full of concerns about the future of this framework.

I have seen Wojciech Seliga last year on Java Developers’ Day, where he’s been talking about Crucible, code review tool his company is developing for Atlassian. This time he shared with us some of his experience in working using agile methodologies. I must admit I was pretty amazed how well they adapted Scrum, especially in the field of their relationships with customers. Some people didn’t believe them when they promised to deliver first running software version after a week (one sprint). But they did and this is how they achieve customer trust. Probably one of the most successful companies implementing agile, proving it can really work and bring money. Lots of respect to you guys!

Piotr Jagielski had a whole speech about test code refactoring (and actually – test code quality at all). The most important idea from his lecture: if some setup/data is not important for the test, it is important to not include it in this test. For instance, suppose you are testing that creating Person object with birth date in the future should throw IllegalArgumentException. Unfortunately, the only available constructor requires, besides birthDate, also firstName and lastName. Supplying fake names would do the trick, but the test method is now cluttered with irrelevant setup code. Moreover, the reader of this test code might not be so sure about fake names irrelevancy. Some flavor of Builder pattern, introduced by Piotr, is the good solution for this problem. Or one can simply use Groovy with its ability to pass arbitrary property -> value map to the constructor call. I suggested Piotr he could benefit from using Groovy, but seems like he’s not using it for testing purposes.

After the lunch my time has come. Project Voldemort - when relation database is not enough (too much?) lecture taken place in Boolean room (BTW: great idea of naming conference rooms after Java data types according to their size!), here is the English translation of the presentation:

...and one of the photos taken during my presentation, thanks to Javarsovia 2010 gallery: