Externalize all API Strings into properties
Opened this issue · 10 comments
to avoid duplication and to keep more organized.
There are few constants in org.neomatrix369.apiworld.APIReader that could be extracted to a properties file that could be read at Startup of the application using Maven.
Extend this to more constants potentially in other classes.
I can help.
Very good, please @danielsoro i going to create the structure and write some samples so you can continue on ok ?
Ok @HelioFrota.
See the sample: 3975f80
Will be great if we can externalise many such constants!
@neomatrix369 yes sure !
3975f80 is not such a good example. It does not make sense to externalize things like '[' etc that do not change.
Property files are only a good idea for things that can actually change. e.g. the names of the endpoints that get accessed.
Property files always come with a cost of indirection. Only when it makes sense to be able to change a system by changing a property in a properties files as opposed to updating to a new version of the library then a property file is justified.
Just because something is a constant is not a reason to add it to a property file.
Not all values need to be in the property file, but a good number of constants can be placed there. Otherwise in a central Java class - as private static final entities!
But explain the reason why.
On Oct 1, 2013 11:53 PM, "mani" notifications@github.com wrote:
Not all values need to be in the property file, but a good number of
constants can be placed there. Otherwise in a central Java class - as
private static final entities!—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-25494811
.
If in a properties file, the values that need to be changed, can be changed without having to make source code change/rebuild/test etc...
Not every value need to be in this file but pick and choose! Like mentioned '[' doesn't need to be in the property file. But a central file containing these values should be maintained. And if from this central class file a number of values are read off a properties file - then we could check if there is an advantage by doing it it.
Lets also inquire with the original author - there must be another illustration of such a practise - I don't see it as a new invention.
Not cumbersome at all - not difficult, and can't see why simple design is breached by doing it! .
Frankly I;m not bothered by it being read from property files - atleast its not open to duplication or scattered like literal text all over the codebase - here's all the explanation, can we pls now focus on other interesting aspects of the code base ?