Samstag, 15. Dezember 2007

Instantiating Generic Type Parameters with Factory Pattern

Some weeks ago a cowoker of mine asked me for help. He wanted to write a class with generic parameter type and create a new object of this generic type inside the class. I.E. he wanted to write something like this in Java:


public class WrongSyntax<T> {
public void someMethod() {
T object = new T(); //this line does not compile
}
}
There are some reasons why this code can't compile. Most evident reason is that T could be an interface and you can't instantiate an interface. And you have to be aware generics are boiling down to one rule : Generics are a double-check on compile time but at runtime the type parameter will be replaced by java.lang.Object and casts to the parameter type. This effect is called type erasure.

If you use java.lang.String as parameter type (and the compiler would not reject the marked line) this class would be replaced by:

public class WrongSyntax<T> {
public void someMethod() {
String object = (String) new Object();
}
}

You would get a ClassCastExcetion on runtime, therefore the compiler does not allow it.

Some days ago I read an article by Angelika Langer & Klaus Kreft regarding this problem in the German Java SPEKTRUM magazin. I'm afraid you won't find it online but there is an excellent english FAQ about Java Generics on Langer's site.

In this said article they discuss the problem of array and simple type instantiation for type parameters. Even though they brought up several solutions for arrays they came up with only one for simple types: Using reflection.


public class UsingReflection<T> {

public static <T> void createInstance(Class<T> clazz) {
T instance;
try {
instance = clazz.newInstance(); // does not work for every class
} catch (InstantiationException e) {
//...
} catch (IllegalAccessException e) {
//...
}

//...

}
}


While this will work for some classes it is obvious that it will not work for interfaces, abstract classes and classes without a default constructor.

Here are two examples that will pass the compiler but fail on runtime:



// throws java.lang.InstantiationException
new UsingReflection().createInstance(Serializable.class);

// throws java.lang.IllegalAccessException
new UsingReflection().createInstance(AbstractCollection.class);



To my mind there is a reason why instantiating type parameters is so difficult. In the first place generics are a double-check for programmers to avoid class cast exceptions. But there is more to it. Using generics brings you the benefit of decoupling an algorithm from the type it works on. But if you are trying to create a new instance of this type your generic code isn't indepent from this type anymore.

Fortunately there is a solution to the problem known from one of the most referenced books in software engineering - the GOF-Book. It's called Factory Pattern. And with generics the factory pattern is even more powerful. Your factories only need to implement the generic Factory interface


public interface Factory<T> {

public T create();

}


and your generic algorithm can trustfully rely on it.


public class UsingFactory<T> {

Factory<T> factory; // or maybe use Factory<? extends T> factory;

public UsingFactory(Factory<T> factory) {
this.factory = factory;
}

public void someMethod() {
T instance = factory.create();
//...
}

}


Object creation and object using are now decoupled, while the algorithm and the type it works on are decoupled too.

Now you can even implement a class GenericFactory<T> which uses reflection for instantiation. But you don't have to. You aren't forced to use a class with default constructor for T. But generics still work for you and the compiler will complain if the factory type parameter and the type parameter of your algorithm do not match.


// SimpleString creates Strings just like everybody does
Factory<String> simpleStringFactory = new SimpleStringFactory();

UsingFactory<String> useSimple = new UsingFactory<String>(simpleStringFactory);


// instantiates a factory that creates Strings via reflection
Factory<String> stringFactory = new GenericFactory<String>(String.class);

UsingFactory<String> useString = new UsingFactory<String>(stringFactory); // this works like expected

UsingFactory<Long> useLong = new UsingFactory<Long>(stringFactory); //type params do not match; does not compile

Donnerstag, 29. November 2007

Martin Fowler on Domain Specific Languages

Recently I was on Martin Fowler's site and lerned about his new - yet to be written- book about DSLs. One or two days later I found this video on InfoQ where he's giving an introduction to DSLs and is showing how the DSL representation can be intern or extern.

For his book I hope he is going really deep into the possibilities of definig DSLs with closures. I've seen some impressive builders composed with closures by the Grails folks. I'm not really sure, but closures seem a lot more powerful, easier to use and clearer to read when it comes to intern Domain Specific Languages then Java5 methods are.

But in the end of the day it all boils down to how powerful your DSL should be and what the best syntax for it is whether you use an intern language, XML or simple representation.

Update: Just today I read this post by Stephan who links to a some other blog postings related to DSLs. He tried to rewrite the Grails HTML Markup Builder in Java. And he seems to share my opinion about closures enabling more powerful DSLs.

Dienstag, 27. November 2007

Using Enums as Proxies/Decorators in Java - forget about switch

Every Java developer knows that you have enums in Java since Java 5.0.

Enums are cool. Especially the ability of getting the right instance of an enum-class by calling the static valueOf()-method with the respective name string makes enums a nice choice in configurations.

In this example I'm using an enum to determine the style of notification for an event or user.


public enum NotificationType {
NO_NOTIFICATION,
EMAIL;
}


While NotificationCommand is a simple interface with implementations like DoNothingCommand, EmailNotificationCommand and SmsNotificationCommand:


public interface NotificationCommand {
void execute(NotificationCmdReceiver rec);
}


Like I said, we want to determine the type of notification by the NotificationType enum.

Most people use enums in switch-statements like this:


public void notify(
NotificationType type,
NotificationCmdReceiver rec) {

NotificationCommand cmd;

switch (type) {
case EMAIL:
cmd = new EMailCommand();
break; // DO NOT FORGET THIS BREAK OR IT WILL BREAK YOUR NECK
case NO_NOTIFICATION:
default:
cmd = new DoNothingCommand();
break;
}

cmd.execute(rec);
}



I myself hate switch/case statements and I think switch/case/break is not OOP-style.
Everytime I use this kind of statement I make mistakes. Often I forget to test some of the several paths of execution, sometimes I forget a break, sometimes I forget the default case and so on.

One problem in particular is refactoring switch-break-statements from or to a version where you use (multiple) returns inside the switch. NEVER DO THIS WITHOUT GOOD UNIT-TESTS!!! (I write from experience...)


So this would be a better version because it eliminates the switch statement.


public enum NotificationType {

NO_NOTIFICATION(new DoNothingCommand()),
EMAIL(new EMailCommand());

NotificationCommand command;

private NotificationType(NotificationCommand command) {
this.command = command;
}

public NotificationCommand getCommand() {
return command;
}
}


You must be aware, that this version does not recreate a new Command-Object for every call. If you want to do so, you have to write something like this:


public enum NotificationType {

NO_NOTIFICATION{
public NotificationCommand getCommand() {
return new DoNothingCommand();
}
},
EMAIL{
public NotificationCommand getCommand() {
return new EMailCommand();
}
};


public abstract NotificationCommand getCommand();
}


In both cases the notify()-method looks like this:


public void notify(
NotificationType type,
NotificationCmdReceiver rec) {

NotificationCommand cmd = type.getCommand();

cmd.execute(rec);
}


Much more simpler, isn't it? (Update: Okay, I have to admit that it actually does not look simpler. But thats because this example simplifies the logic in the different switch-cases a lot. In real world projects there will be more than 2 different enum values (which means more breaks) and there are more lines for each case. Using this technique lets you break up this one method into some smaller ones. To my mind it's much easier to test n different methods with one execution path each than to test one method with n different execution paths.)

But you can do even more simpler. While it is true that all emums in Java inherit from java.lang.Enum and can't extend any other class, developers seem to forget that enums can implement interfaces:


public enum NotificationType
implements NotificationCommand {

NO_NOTIFICATION{
public NotificationCommand getCommand() {
return new DoNothingCommand();
}
},
EMAIL{
public NotificationCommand getCommand() {
return new EMailCommand();
}
};


public abstract NotificationCommand getCommand();

public void execute(NotificationCmdReceiver rec) {
getCommand().execute(rec);
}
}

The enum NotificationType is now something like a decorator / proxy for NotificationCommands. And the notify()-method boils down to only one line:


public void notify(
NotificationType type,
NotificationCmdReceiver rec) {

type.execute(rec);
}


And now you see much clearer that this method could be static. To my mind, often static methods are a signal of poor design and should be refactored. You can inline the last line and remove the notify()-method.

Update: I want to stress that this post actually is more about that enums are able to implement interfaces and it can be useful to do so than it is about not using switch. In fact even if you let your enums implement interfaces you still can use them with switch. But additionally you get all the advantages that comes with it, especially to use your enum transparently.

Mittwoch, 21. November 2007

Message Routing with Apache Camel

When I was in Munich for WJax (see my previous post) I was talking to some people about my current project at my dayjob. We are building a big distributed system for logistics where you have several warehouses, distributors and suppliers. We use ActiveMQ and ServiceMix to let the different applications talk to each other. So message routing is something we need to have but is only partially implemented in our system.

The people I talked to recommended to check out Apache Camel for message routing. So did I and was really impressed. Camel uses an internal DSL for configuration which is very simple and intuitive. The Camel developers even show how to implement most of the Enterprise Integration Patterns in the Camel wiki. On top of that Camel has implemented support for a lot of components.

Freitag, 9. November 2007

My WJax Review

I just came back from W-Jax/SOACON yesterday where I've seen a lot of great talks. Three days of high quality input can really make you feel your synapses growing in your brain.

I learned a lot of things while staying in Munich. MVS (Most Valuable Speaker) for me was Gregor Hohpe who is a really cool guy. He is co-author of one of my favorite books (Patterns of EAI) and I was really excited to meet him in person.

He was the first one who made clear to me what SOA is really all about, something that all these SOA hype business people never were able to. You don't know how annoying these people are. These people make you feel like a second class citizen if you don't have WS-* everywhere and use some BPEL and BPM and BLA BLA BLA.

But thanks to Gregor, now I know that we are on the right track. More than that I know we can reach leading position if we abstract a little bit more here and do some looser coupling there, etc. Nothing to difficult, nothing to worry about, just utilizing more patterns and make things work.
I had a very nice discussion with Gregor and almost missed my flight from Munich back to Berlin.

Gregor Hohpe also was the one who encouraged the audience to write more blogs and articles about patterns and related topics. And this is exactly what I'm trying to do right now. ;-)

But I learned a lot more things on W-Jax. I attended some talks about OSGi which soon will be featured in every serious Java project. I swear. In 2009 you won't see any bigger Java project (open source or not) which isn't OSGi-enabled. I bet Peter Kriens would tell you the same.

And I attended some talks about the Java language, Groovy and Spring.

These guys from interface21 seem to be really busy these days. They just released Spring 2.5 and are working hard on Spring Webflow 2.0 and Spring Batch. I'm thinking about using Webflow as lifecycle controller in my project. As far as I know do they try to utilise Spring Webflow to manage the JSF lifecycle.

Groovy lead Dierk König showed off some really cool Groovy stuff. I have to admit I bought 3 books on Groovy & Grails and 2 Spring books approx one year ago and never had time to do more than a little Grails demo. Shame on me. I promise I will do more with Groovy. Hopefully my team leader at my dayjob will allow me to use it.

Angelika Langer showed some cool stuff she did with Java annotations. I use annotations on my project too, but it's astonishing what different things you are able to do with them at compile time and runtime. Someone should really write a book about annotation patterns.

By the way, does anybody know a good book about AOP patterns? Runtime annotation analysation with reflection seems to be a lot like AOP to me and I want to know more about that.

Powered By Blogger