Thread: How to Logically Break Down a System for Inheritance

You could create multiple layers of inheritance. Something like this:
Location (abstract or interface) - contains: name, area
POI (concrete, extends/implements Location) - contains any new stuff
PopulatedLocation (abstract or interface, extends/implements Location) - contains: Continent_Name, population
Continent (concrete, extends/implements PopulatedLocation) - contains any new stuff
Country (concrete, extends/implements PopulatedLocation) - contains any new stuff
City (concrete, extends/implements PopulatedLocation) - contains any new stuff

So POI and PopulatedLocation inherit from Location. PopulatedLocation contains the stuff that POI doesn't care about. Then, Continent, Country, and City all inherit from PopulatedLocation. Since PopulatedLocation is-a Location, and Continent/Country/City is-a PopulatedLocation, Continent/Country/City are also Locations.

You could do something like that, but there are probably better options.
When designing a data structure, you need to ask: how am I going to access the data?
Should the data ALWAYS be sorted a specific way and will you ALWAYS search by the name? If yes to both of those, perhaps a SortedMap would be better than a LinkedHashMap.
Will you be searching in ways other than just by name? If yes, use a List instead of a Map, because a Map would provide you with absolutely no improved performance if you search by anything other than the key (probably decreases performance even).
Should all the counties, cities, ect. be stored together instead of in different Maps/Lists?

In case you don't fully understand inheritance, you can create a generic list and add child objects into it. For example, an ArrayList<Location> would accept counties, cities, POIs, ect. all together, since they all inherit from Location.

Ok, I'm going to suggest a bit of a different take on this. We are going to use some creative data storage and referencing to reduce your need to do lookups and whatnot.
Tell me if these guidelines make sense:
Framework:
1. Create a helper class. This helper class should contain:
a) static Lists for each Location type (ie: one of continent, country, ect.)
b) 3 static methods for each list: set, get, add
2. Country should not contain a String name of a Continent, but rather a reference to a Continent object. Additionally, City should not contain a String name for Continent or Country, but references to Country and Continent objects.
Logic:
1. When a new item is read into the program, you will dynamically populate the lists in the helper class with any locations, including dependent ones. In order to do this, our helper methods need to have a bit of extra logic:
a) the "get" method needs to find the corresponding Continent, Country, ect. in the list. If one does not exist, we will dynamically create a "templated" version, add it to the list, and return it. This ensures that the Country "Europe" will exist, even before we read it in.
b) the "add" methods will add new Continents, Countries, Cities, ect. to the lists. But, before adding, it first needs to determine if a conflicting one already exists. If a conflicting one does exist, we need to overwrite the existing one with the new data we are reading in. These conflicting versions will be the "templates" mentioned in part a. We need to update the templated version to include all the data we are reading in.
2. So, let's say the first thing we do is read in Germany. The logic would go like this:
a) Create a new Country object with the name: Germany. While creating the new Country object, we need to lookup the Continent: Europe.
b) Helper.getContinent("Europe"); Europe is not found in the Continent list, so we create a new Continent with the name: Europe (no population or area data yet), add it to the Continent list, and return the new Continent.
c) We now have the Continent Europe, we add it to Germany's Continent variable, and we add Germany to the Country list
d) Helper.addCountry(germany); Searches the list for an already existing Country named: Germany and doesn't find one, so the new country is just added to the Country List.
3. Now let's read in Europe:
a) Create a new Continent with the name: Europe. Add the Europe to the Continent list.
b) Helper.addContinent(europe); Searches the list for an already existing Continent named: Europe and finds the templated one we created earlier for Germany. Instead of adding the new Continent, it instead copies the area and population values from our new Continent into the template.

Germany's reference to Europe has not changed, but the area and population values in the Europe instance has been updated. So if Germany wanted to see Europe's area and population, it already has access to that without any additional lookups.

Tell me how much of this makes sense. We are doing a dynamic lazy-load (which means: loading data on a need-to-have basis instead of arbitrarily). When we initially load Germany, it will not have all of Europe's information, but that is ok, because that information will update itself later when we load Europe's data in. Furthermore, we only need to look up the continents for each country once: when we load the country in. From then on, we have a reference to the country's continent, so we don't need to do any additional lookups later to find a country's continent.

Currently I have a Location object class that has the variables for continent name, population, area and then Continent, Country, City and POI objects that extend the Location class.

Here's my take (I did not read through every word of the above posts so I hope it's not redundant): I see no need for inheritance (based upon the information given). Inheritance can be beneficial in cases where behavior should be implemented/altered - which I don't see in this case, rather it seems you wish to classify Locations (correct me if I'm wrong). If this is the case, then specify it's type by, say, adding a method which returns an Enum type specifying type (Continent, Country, etc...). This can also allow you to Map type to a Collection of Locations so you can search by type (if you so desire). You can also, if necessary, organize the data intro a Tree/Graph - in which each Location has one or more parents and children - the parent being its containing Location and children Locations it contains - this more complicated step may not be necessary depending upon how you wish to access the data.

My advice going forward would be to write down what methods are required for accessing the data (I'm still unclear at this point what that may be so I can't be specific) - this is the contract (aka Interface) which allows clients access to the data. Say, for example, it might have a method like 'searchContinentsByName(String name)'. Doing so can help define both what a client can access, as well as help you define how you wish to organize and implement 'under the hood'.

It makes sense, however I have been encouraged to encapsulate the data fields. Therefor by making the Lists static it will not meet that criteria. I should mention I will eventually expand this project to utilize the MVC (Model View Controller) for the interface.

It shouldn't violate that. When you load the data in, you have to load it into somewhere. What I was suggesting was a single central data core which can be used to lookup values.
Perhaps it would make more sense if I just showed you:
[highlight=java]
public class Helper {
private static List<Continent> continentList = new ArrayList<>();
private static List<Country> countryList = new ArrayList<>();
private static List<City> cityList = new ArrayList<>();
private static List<POI> poiList = new ArrayList<>();

public static List<Continent> getContinentList() {
return continentList;
}
public static void addContinent(Continent toAdd) {
// check list before adding, and only add if it already doesn't exist
}
public static Continent getContinent(String name) {
// find the continent with the requested name and return it, create a template if it doesn't exist
}
public static List<Country> getCountryList() {
%0