Re: Interface design considerations
- The SLVC places the responsibility of handling the locale
information on the calling class. The implementation class can be very
well implemented using the Singleton design pattern since no
additional information is required when translating text.
The contract will be burdensome if translation is very complex (e.g.,
the semantics for French->English translation are very different from
those of Japanese->English). It will also be burdensome if several
translation requests will be performed in sequence in the same locale.
- The SFMC places the responsibility of handling locale information on
the implementation class. One of the ways in which this can be done is
make the implementation class provide setter or hook methods for
setting the locale information though any other approach for
retrieving the locale information can be used.
I envision implementations of this methodology to either be able to
translate only one locale to another, or to have the class user to
manually supply the information at construction.
- The SFVC is a verbose version of SFMC which mandates the
implementation class provide hooks for setting the Locale information
i.e. mandates the implementation class be Stateful.
This is like the first one, except it has more shorthand, since it would
expect translation to be in "bursts" (i.e., translate would be called
with the same locales repeatedly).
I'm personally leaning towards the first approach but would very much
like to hear what is the general thought process which goes behind
when designing interfaces in general. Comments and suggestions
It depends. My gut reaction, in lieu of any other context, would be to
go more towards the second one (since I expect that translation would
mostly be between the same two locales and that it would be rather
specialized). The third one would be my second choice, and the first my
The decision ultimately comes down to usage patterns and implementation
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth