2

I am creating an android app for pharmacy duties for different cities.

My approach:

I created an Interface with method getDuties, and for every cities I create a class named with name of the city example:

public class AthensProvider extends CityProvider

Inside this class, I have the logic for parsing and returning duty objects.

Finally, in when the user changes city preference I have something like this:

CityProvider provider = ProviderHelper.getProvider(city);
provider.getDuties();

Is this approach correct?

6
  • What happens if you want to add a new city ? Do you need to recompile and redeploy your app ? Mar 4, 2016 at 9:54
  • @X.L.Ant I am adding all available cities ( all cities in my country) in the first version of my app.
    – Giannis
    Mar 4, 2016 at 9:56
  • Seriously ? What's so special in each city provider that each needs a dedicated class for it ? Why not just a CityProvider property that would host the city name ? Mar 4, 2016 at 10:13
  • I would have to agree. Are each city really unique in this matter, or could it be achieved by a simple CityProvider instance, with different data depending on which city? For me it seems like a massive redundancy and overhead to create a different class for each city.
    – Niklas H
    Mar 4, 2016 at 11:45
  • @NiklasH The scraping for each city is entirely different. Each city has it's own site where they provide the duties, I parse and save them in a local db for each day.
    – Giannis
    Mar 4, 2016 at 11:55

2 Answers 2

2

Duties sounds like something that should be in a database or configuration file. Having custom code in your app for each city sound like a maintenance nightmare waiting to happen.

1

If duties will not ever change over time or will change very rarely (e.g. once in a quarter), it may be a good idea to hardcode them in code rather than using a database.

In this case you could try an enum-based design:

public enum Duties {
    ATHENS {
      public String[] getDuties() {
        return {"a", "b"};
      }
    },

    SPARTA {
      public String[] getDuties() {
        return {"c", "d"};
      }
    };

    abstract public String[] getDuties();
}

Then you will be able to get duties with following code:

Duties.ATHENS.getDuties()

In case of hardcoding anything it's always a good idea to rationalize it a comment.

If duties will change often you may want to consider storing duties for each city in a data base and synchronizing them with information stored on the server during application's start-up.

2
  • Why could it ever be a good idea to hardcode duties?
    – JacquesB
    Mar 4, 2016 at 11:00
  • Less files in the project, less platform components used, less IO, less dependencies, less maintainance work. Mar 4, 2016 at 11:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.