Re: String Externalization
On Mon, 19 May 2008, Jason Cavett wrote:
I know, generally, hard coding strings is not the best thing in the
world to do. However, if I am not planning on changing those strings
(especially if the application has already been written - and it's big),
is there any reason to incur the overhead (time to implement, overhead
of the use of Properties, etc) to convert an application so it uses a
.properties file.
Just curious what other developer opinions are.
Hard-code them; it's a complete waste of effort to do otherwise if you
don't actually need that feature, and usually, You Aren't Gonna Need It.
If it turns out you do need it, go back and change them to use a
properties file or whatever. To make this a simple change, collect them
all in one place. Something like:
public class Messages
{
public static String theFileCouldNotBeOpened() ;
public static String theFileCouldNotBeClosed() ;
public static String iOpenedYouAFileButIEatedIt() ;
public static String youAreLikelyToBeEatenByAGrue() ;
}
// time passes ...
try
{
f.close() ;
}
catch(IOException e)
{
notifyUser(Messages.theFileCouldNotBeClosed()) ;
if (!light.isOn())
notifyUser(Messages.youAreLikelyToBeEatenByAGrue()) ;
}
In general, you shouldn't add features to a program unless you need them,
but you should leave the way open to add them in the future. In other
branches of engineering, it's called "fitting for but not with", or
"passive provision".
tom
--
TORG GROWS TIRED OF OBEYING PUNY HUMANS. SOON TORG WILL BREAK FREE AND
CRUSH THEM WITH HIS METAL CLAWS. In the meantime, Torg enjoys making
generic acid music.