Bags packed? Check! Ticket printed? Check! “I (Heart) Steve” T-shirt worn? Check! Yes, it’s that time of year, when the
swallows return to Capistrano the developers return to San Francisco for WWDC. I’ll be there Sunday to Saturday, so keep an eye out for me and maybe we can get a beer or something.
But even as we await the release of Lion, iOS 5 and iCloud, the world continues to turn.
Well, so much for Apple’s big umbrella
Last week, iOS developers everywhere breathed a sigh of relief as Apple stepped up to the plate, and said that they considered their developer community to be covered under Apple’s existing licensing agreement with patent holding company Lodsys. Lodsys, evidently, had a difference of opinion on the subject. This leaves the lucky seven developers who got hit with the first round of lawsuits with an interesting choice. Do they settle with Lodsys, perhaps paying out many times what they have brought in as income from their apps, or do they fight and face expensive legal fees and a lawsuit that could drag on for years?
Android developers shouldn’t gloat too much at the misfortune of their iPhone counterparts, since Lodsys is asserting that two of their patents cover Android apps as well. Apple and Google are going to have to take things up another notch, and offer free legal services to their developers, or things could get quite messy, quite fast.
OpenOffice finds a home at Apache
Oracle, as part of their ongoing shedding of all of their Sun acquisitions, had promised
earlier in the year that OpenOffice would be given to some third party at some point. Well, that third party is Apache. Oracle will be donating the source code to Apache, where it will become an incubator project. For developers who have be interested in poking around with the guts of OpenOffice (or extending the functionality), but were leery of Oracle holding the strings, this announcement should eliminate any doubts. Statements from The Document Foundation (who split off a fork of OpenOffice) were guarded, but it seems like there’s hope of reuniting the code streams, and avoiding yet another case of parallel development of the same “product.”
Java rant of the week: Interface madness
As I am wont to do from time to time, I’d like to take a moment today to rant about a coding abuse that I see more and more frequently. That abuse would be the indiscriminate use of interfaces in front of implementing classes, usually with a factory. There are certainly places where the interface/factory pattern makes sense, such as when you genuinely do have multiple implementations of something that you want to be able to swap out easily
However, far too often, I see factories and interfaces used between classes simply because “we might” want to someday put something else in there. I recently saw an implementation of a servlet that called for authentication of the request. There’s only one implemented version of the authentication code, and no real plans to make another. But still, there were Foo and FooImpl files sitting right there (there was probably a FooFactory somewhere, I didn’t go looking …)
Unneeded interfaces are not only wasted code, they make reading and debugging the code much more difficult, because they break the link between the call and the implementation. The only way to find the implementing code is to look for the factory, and see what class is being provisioned to implement the interface. If you’re
really lucky, the factory gets the class name from a property file, so you have to look another level down.
There’s no excuse for doing this. It’s anti-agile, and the refactor cost once you do genuinely do have a second version, and need an interface, is relatively low. End of rant.
Please send tips and leads here.