Encapsulate fields on the Location class #9
Comments
Hi Nicolas, I think you should create a new class to provide the getters and setters. It is unlikely we change the current behavior b/c the newly protected fields break everyones code. Boris Am 01.08.2013 um 09:03 schrieb nguillaumin notifications@github.com:
|
Thanks for your answer, indeed that's what we plan to do but I thought that it would be nice to have that fixed upstream... I understand the compatibility issue though. |
Depending on your use case, you might want to look into our beta GeoIP2 API, https://github.com/maxmind/GeoIP2-java. It uses our new database format and corrects this and many of the other issues in our legacy API. |
Is it possible to run GeoIP2 with the local data file? I cannot find a way to download it? |
We provide GeoLite2 City at http://dev.maxmind.com/geoip/geoip2/geolite2/. We do not yet offer our paid databases in the GeoIP2 format. |
Thanks for the suggestion about GeoIP2, it looks it'll suit our needs! Happy for this issue to be closed. |
I'm happy to hear that. I'll close this issue. |
Hi,
The
Location
class has various properties likecountryCode
,countryName
, etc. which are public fields (as opposite to private fields with getters / setters).Not only it breaks basic OO encapsulation principles, but it makes it difficult to work with some frameworks that relies on the presence of getters and setters to introspect fields on an object.
The specific case I have is with the FreeMarker templating engine: It relies on getters and setters, meaning that such a
Location
object cannot be used within a FreeMarker template since its fields are not accessible.I can think of other cases where that would be a problem, such as XML or JSON serialization / deserialization where the getters and setters might also be important.
Is there any reason why those fields are public and not private with getters / setters ? Would it be possible to make them so ?
Thanks,
Nicolas
The text was updated successfully, but these errors were encountered: