1

My task is to create a translator, as I have discussed earlier in this thread. How do you use a generic type as return value and a generic type as a parameter?

Short, I have one language that needs to be translated in another. Like this.

public abstract class Translator <T extends OriginalText, V extends LanguageTranslation> {            
    public abstract V translate(T originalText);
}

The new challenge is, that at design time I do NOT get a sub class of OriginalText to translate, but rather an instance of the super class OriginalText. Thus when I call an implementation of the translate function, I'm able to set the specific LanguageTranslation V, but need to remain OriginalText, as oppose to EnglishText, ChineseText, etc, which are sub classes.

// I know response type V (specific class of LanguageTranslation) from a parameter from this function.
// However, this is non-sense anyway, because Translator is abstract.
Translator<OriginalText, V> translator = new Translator<OriginalText, V>(); 

// At design time, I have no clue what is returned by the repository. Hence, I expect the translate method to do the appropriate decision at run time.
vType = translator.translate(repository.getTextObject(textId))

I want my translator - or a factory - to translate in a way that is specific to the OriginalText (sub classes have several different attributes) and the LanguageTranslation sub type I have provided. There is a one-to-one matching. However, I do not know this at design time! I need something like a Factory to create this translator for me, right? Other approaches? Double dispatch?

Community
  • 1
  • 1
feder
  • 1,775
  • 5
  • 25
  • 36
  • Can you show the actual method you are using for translation? Are you using some translation method from `OriginalText` class? – Rohit Jain Oct 02 '13 at 13:41
  • Please specify how you want to call the translator. You can use Object#getClass() at runtime to get the implementation class of your text from an instance so I don't see the difference... – AlexR Oct 02 '13 at 13:47
  • To answer you last question first: Yes, there are common attributes that all sub classes of OriginalText have in common and need to be translated (So, abstract class over interface). To answer your first question: The translator should simply read the special attributes of the sub classed of OrignalText and copy it to the LanguageTranslation with minor changes and translations. Nothing special, but certainly properietary treatment for each. – feder Oct 02 '13 at 13:52
  • `Translator` is abstract. So how can you do `new Translator()`? – newacct Oct 03 '13 at 00:09
  • @newacct Yes, non-sense. I'm basically rather look for an approach than someone who codes this for me. Sorry, I was not clear. – feder Oct 03 '13 at 04:52

1 Answers1

1

First, I think your Translator should be an interface, not a class. I'm also not sure I understand why you have a class for each source language.

That being said, somewhere in your design you're going to need a black box that gets a common text object and returns a corresponding translator. As long as you return a translator that matches the input type, you can live with the lack of static type safety from having a translator that uses OriginaText. Note that this black box is not going to be a translator. It should be something that can provide an appropriate provider. If you actually need new instances of translator for each text, this can be an Abstract Factory (http://en.wikipedia.org/wiki/Abstract_factory_pattern)

The implementation of this factory depends on your program. If you have a limited set of languages, you can have a bunch of if statements that use data about the OriginalText (such as its actual class name, or some clue in the text). If this is flexible, you could write logic that registers Suppliers of concrete translators for specific criteria, and then programmatically find the first item that matches the criteria given the text.

Uri
  • 88,451
  • 51
  • 221
  • 321
  • I have a class for each source language, because they might be translated by different approaches. Using different methods, attributes, etc. I was looking into the factory pattern with if-ladders before. I dislike the approach of if-ladders. I rather though of a class that determines the imlementation to use by a class. Similar like the overloaded-method of a visitor pattern. But that is single-dispatched. Hm. Challenging, I think. I need to look in something like this. http://stackoverflow.com/questions/12628251/java-factory-pattern-with-generics – feder Oct 03 '13 at 05:35