Re: Interface design considerations II - Exceptions, Sessions, Testability

From:

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>

Newsgroups:

comp.lang.java.programmer

Date:

Tue, 14 Jul 2009 19:30:49 -0400

Message-ID:

<4a5d1524$0$48246$14726298@news.sunsite.dk>

sasuke wrote:

Thanks to all the suggestions provided in the previous thread <http://
groups.google.com/group/comp.lang.java.programmer/browse_thread/thread/
f21886dbb1dbfa71/>, I was able to come with a basic implementation of
my translation library. The interfaces I ended
up creating are:

public interface ITranslator {
  String translate(String text);

}

// This is implemented by classes like GoogleTranslatorImpl
public interface ILocaleTranslator extends ITranslator {
  void setFromLocale(Locale fromLocale);
  void setFromLocale(Locale fromLocale);
  Locale getToLocale();
  Locale getFromLocale();

}

// This is implemented by classes like PropertiesFileTranslatorImpl
public interface ITextFileTranslator {
  void setTranslator(ITranslator translator);
  void translateFile(File inFile, File outFile) throws
TranslationException;

}

I would drop the I prefix on interfaces. Not very java'ish.

Having reached this far, I still have a couple of queries:

= Let's suppose I've a very simple Socket server for dealing with
translations. For translating each piece of text I:
  - Connect to the server socket
  - Send the request
  - Receive the translated response
  - Close the resources

What would be a good way of introducing the concept of session in my
library implementation wherein the user can take advantage of using
the same connection [if supported] for all its translations during a
session instead of creating and destroying the socket connection for
each piece of text? I was thinking along the lines of having a `init
()' and `destroy()' methods which would be invoked by the client to
initiate or destroy a translation session respectively.

What are the session going to provide that the Socket does not?

The easiest way of keeping things separated server side is to have
a different instance of the relevant object per client.

= What would be a good way of handling exceptions when creating such
general purpose libraries? Right now I have a single exception class,
TranslationException which extends RuntimeException for this. It
encapsulates all the checked exceptions thrown by the application by
catching all the checked exceptions and wrapping them like:
  try {
    // any piece of code
  } catch(Exception e) {
    throw new TranslationException(e.getMessage(), e);
  }

I would only catch checked exception and maybe a few specific
runtime exceptions.

And I would throw a checked exception.

Much more transparent.

= How would I go about writing test cases for translation
implementations which require external resources like a socket
connection to the translation service and so on? Let's assume my
implementation class looks something along the lines of:

Mock object.

Arne