Fall 2005, David Matuszek
Yoda is a little green alien. He speaks English, but his grammar is a little funny. Extend your language translator to handle "Yoda-speak" ("Yoda" for short).
Translate the words to English.
Verb rule: Apply the English verb rule, then move the verb, along with any preceding noun (
NOUN), determiners (
DET), and adjectives (
ADJ), to the end of the sentence. So, for example,
"the man sleeps on the table"becomes
"on the table the man sleeps".
Adjective rule: Same as English.
Since Yoda uses the same words as English, when translating Yoda → English or English → Yoda, the easy thing to do is to use the English word list as both the "from" word list and the "to" word list. You could save a few nanoseconds by omitting the word-by-word translations. This is a good example of the kind of optimization you should not make.
Notice that our verb and adjective rules depend only on the "to" language, not on the "from" language. This makes certain translations more of a problem. In particular, while you should be able to translate English to Yoda reasonably well, going from Yoda to English may not do anything, or it may mangle the sentence. Don't try to fix this. Your job, in this case, is to try to get the translation project funded for another year.
Document everything that has
"package" access. You are welcome to document things that have
access, but this is not required. Do not put Javadoc comments where they
do not belong, such as in front of local (method) variables.
For each class or interface, provide:
@authortags. Don't put names in parentheses.
@versiontag, giving either a version number of some kind, or the date.
For each constructor, provide:
For each method, provide:
@param nametag for each parameter, saying what information it needs to hold.
@returntag (unless the method is
void), saying what information is returned.
@throws exceptionNamefor any checked exceptions your method throws. (There probably won't be any in this assignment.)
For each constructor, provide the same kind of information as for a
method, except that you should not have a
@return tag for a constructor.
For each instance variable or static variable, provide:
Often you will find yourself explaining the parameters to a method (or a constructor)
twice, once in the description of what a method does, and again in the
tags. This is somewhat unavoidable, but if you have a good general description,
you can be very brief in the
Avoid describing methods in terms of other methods. Insofar as possible, each description should make sense all by itself.
You should not use static or instance variables for temporary values, such
as the index of
for loops. Every such variable should say something
about the object in which it occurs; if it doesn't, it's in the wrong place.
I have added some buttons to the Translator.java class, which you should download and use in place of the previous version. If you compare these two versions, you will see that I did not need to add anything to the code except the buttons themselves.
I did not change the dictionary classes
Remember, you are welcome to add words of your own to the dictionary (Hint:
but please don't remove any.
You will need a new class,
YodaRules, which implements
In the constructor for your
LanguageTranslator, you will
need to add some code to deal with the "Yoda" language. This added
language should only affect the constructor. Other methods, and in particular
translate method, should not need to be changed. If you do
need to change them, you aren't making good use of interfaces.
I said that your
RuleSet interface should declare the following
void applyVerbRule(String words);
void applyAdjectiveRule(String words);
This can be made to work, but it's a lot more awkward than I intended, because
the methods aren't getting part of speech (
etc.) information. If you wish, you can declare the methods this way
void applyVerbRule(String words, String types);
void applyAdjectiveRule(String words, String types);
where the second array tells you the part of speech of each word in the first
array. For example, if the first array contains
then the second array would contain
I think this will make your code a lot simpler, so the best reason for not
doing it this way is if you already have the program working with the old method
We will pay careful attention to formatting and style.
October 27, before midnight, via Blackboard only.