Re: Interface design considerations
Hi sasuke,
Please find my comments below:
"sasuke" <database666@gmail.com> wrote in message
// The stateless verbose contract [SLVC]
public interface ITranslator {
String translate(String text, Locale fromLocale, Locale toLocale);
}
I would not prefer this alternative because of these reasons:
- I would say it is more usable for clients to set the "from" and "to" once
and call "translate" many times passing only the text e.g. Google Translate,
you set the from and to language once and then keep translating texts away
this is what I always do anyway German => English. Eventually you go back
and "swap" English => German maybe also to check the soundness of the
translation, a nice addition to your Stateful version maybe would be the
"swap" method. Therefore handing to clients an interface that has a method
"translate(String)" would be easier from the usability prospective e.g.
would cover nicely the use-case of configure once upon startup the from and
to and call many times the translate while also supporting the use-case of
changing the from and to continuously.
- In several papers I have read about SE and if I recall correctly most
metrics regarding number of input parameters for a method in average expect
this to be 1 or less meaning one parameter, though Item 40 [1] sustains "Aim
for four parameters or fewer"
- Another factor to look at is the convariant ordering or the interface,
meaning if it is more general (generic) or more specific [2]. This interface
SLVC is more specific than SFMC. More general interfaces like SFMC tend to
be easier to implement as they impose less requirement on implementors i.e.
they don't force implementors to depend on or having to specifically deal
with Locale. Furthermore, having more specific interfaces with more
dependencies increases the values of the OO metrics "AC" Afferent Couplings
and "CBO" Coupling Between Objects [3] [4]. A higher number in "AC" or "CBO"
means more instability and less abstract.
// The stateful minimalistic contract [SFMC]
public interface ITranslator {
String translate(String text);
}
This is a more abstract, less instable choice for an interface, thus you
could hand this ITranslator to layers of your app safely assuming that they
will not be impacted should the implementors decide to change depending away
from Locale or should Locale public interface change.
For all explained before, I think a very good alternative would be:
//
// leave it free for more specific variants to be created and easier, more
stable reuse
//
public interface ITranslator {
String translate(String text);
};
//
// more specific subclass that could be more useful in the configuration
layer of an application
//
public interface ILocaleTranslator extends ITranslator {
void setFromLocale(Locale fromLocale);
void setToLocale(Locale toLocale);
void swap();
};
Best regards,
Giovanni
[1] Effective Java 2nd Edition 2008
http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683/ref=sr_1_1?ie=UTF8&s=books&qid=1245585338&sr=1-1
[2]
http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
[3]
http://satc.gsfc.nasa.gov/support/OSMASAS_SEP01/Principal_Components_of_Orthogonal_Object_Oriented_Metrics.pdf
[4]
http://www.parlezuml.com/metrics/OO%20Design%20Principles%20&%20Metrics.pdf