Question

at work we have an application that, at first, had been developed for a specific country. Now a new client is interested in the application but this client is from another country. We have to change some objects to respresent the new country.

• Country 1, properties A,B,C,D,E so java and Database contains A,B,C,D,E

• New Country 2, properties A,D,F,G,H

Solutions we came up with.

Database :

• Create a new table for the new country

• Simply add F,G,H to the current table

Java :

• Make the current address abstract with A,D then create a country specific implementation (Interesting and clear but adds the pain to work with an interface thus you have to type casts all the time)

• Simply add F,G,H to the address (Seams an unclean solution knowing that the day a new country is to be added may end up with adding I,J,K to the object)

• Modify the current object to have common properties and some generic fields like info1, info2. (Seams a good solution but makes the code unclear by working with info1, info2… in business logic)

Anyone know a good pattern for this kind of problem?

Regards

Answer 1

OK, after the clarifying comments my understanding is:

• You already have a Address class and related database table
• Each country will require a different set of address lines for each Address
• The behaviour of the code for each country is not particularly different (i.e. addresses behave in a similar way, apart from the fact that they have different address lines)

In general, I would avoid creating new classes when the differences are really just pure data. So having two different Address classes seems like a bad idea, regardless of whether or not you make them inherit from a single base class. Also, inheritance hierarchies don’t usually map to databases very well.

I think the best solution is to store the properties for each country in a HashMap or something similar, which then determines which address lines apply for each country. For simplicity, each Address might contain a HashMap<String,String>, i.e. with Strings for both the keys (address line names) and values (address data).

If you do this, then you have a high degree of flexibility over what properties you set for each country, and if you add a third country at some point you might not need any code changes – just a new set of address lines.

In the database I’d represent the data in two tables: Address and AddressLine, with the obvious 1-to-many relationship.