I think I will put the different strategy into a factory. So your Artifact doesn't have to care about all the different ImageSerializer.
So in your Artifact's the method will looks like this:
And the above code can even go into an AbstractClass to remove duplication.
With that you have the injections done into the factory object. You can do case switch or Map, whatever you like.
This way your Artifact doesn't have to know about all available format to support. If you add new format, you just update the factory class. With your existing design, you have to update all your Artifact based classes.
Remember the DRY principle. [ May 08, 2008: Message edited by: Wirianto Djunaidi ]
No, i dont think so. I think the Image class must be unaware of the algorithm used to serialize and this is one way of decoupling the data and behaviors.
Pho: Is there a more correct way to implementing this ?
I think you have not implemented the Strategy pattern correctly. The problem is that you have made the Image aware of different Serializers. Since you have a Serializer interface, you can make the Image class aware only of the interface and not the implementations like JSON and XML. In the serializeTO() method you must not pass the Format as you would have already decided upon the serializer based on the format. You must directly call the serializers serialize method.
The code will look like this:
(Ideally, a strategy should always be of the above form.)
Now, the above will work if an image object while creation knows what it can be serialized into(otherwise you have to either pass it into the serializeTo method or keep on flipping the serializers!)
The other way can be to do an Inversion of control on this design and let the Serializer take the Image as the method argument. (This way you can follow the Visitor pattern in a way. This will be like a JSON/XML serializer for all the artifacts.)