0

A command line currency converter application that prompts for a user input of source currency, source currency code and target currency code e.g. 

C:\workspace> java CurrencyConverter 100.50 EUR GBP

The application returns the value of the source amount converted to the target currency e.g. for the above input it returns

100.50 EUR = 86.33 GBP

After displaying the converted value the program exits.

The available exchange rates (GBP based) are in a comma separated value file. Format of this file is COUNTRY,NAME,CODE,RATE e.g.

United Arab Emirates, Dirhams, AED, 7.2104
Australia, Dollars, AUD, 1.51239
Bosnia and Herzegovina, Convertible Marka, BAM, 2.60565
Bulgaria, Leva, BGN, 2.60948

I have a single java file which does the things but how can I convert it into well designed, extensible and maintainable form that adheres to good OO principals?

Should I consider any design pattern, if yes, what different types of objects/interfaces required and their relationships with each other?

Gladhus
  • 910
  • 1
  • 13
  • 24
Kaizar Laxmidhar
  • 859
  • 1
  • 17
  • 38
  • This program seems small enough that you don't really need a design pattern. Maybe one method for checking the online conversion rate between two currencies, and then applying it to a number. – Rogue Apr 09 '14 at 13:42
  • @Rogue I know this is a small program hence the challenge lies in visualising how and in what way this program could possibly grow in future and accordingly think a good design. Regarding your suggestion of checking online conversion there is no need for that as CSV file is provided. – Kaizar Laxmidhar Apr 09 '14 at 13:50
  • 1
    Design Patterns are methods of solving specific problems, you can't go around and ask yourself if a pattern fits every piece of code you have. Although, this is quite common when you are learning design patterns. Some call this a "disease" called "patternitis". – Henrique Barcelos Apr 09 '14 at 13:58
  • Should the necessity arise by any new requirements, you can always refactor the program (possibly to patterns; there is a very good book "Refactoring to Patterns" by Joshua Kerievsky). Don't overplan and overoptimize at the beginning of a project; most often you get into problems you wouldn't have had otherwise. Just keep your code readable and maintainable. – Uwe Allner Apr 10 '14 at 06:29

1 Answers1

1

Some design aspects I thought of

  • Reading CSV file: Create an ExchangeRateReader factory so that exchange rates files of various format can be used as an input.

  • (Objectify) ExchangeRate POJO objects contains code, name, country and rate

  • Concrete factory class produces ExchangeRate objects reading from CSV file

  • Use of Enum for ReaderType: CVS, TEST, EXCEL //the factory relies on to create appropriate instance (concrete factory instance)

Kaizar Laxmidhar
  • 859
  • 1
  • 17
  • 38