Java Currency Converter 遵循 OO（面向对象）原则答案

【问题标题】：Java Currency Converter adhering to OO (Object Oriented) principlesJava Currency Converter 遵循 OO（面向对象）原则
【发布时间】：2014-04-09 13:40:53
【问题描述】：

一个命令行货币转换器应用程序，提示用户输入源货币、源货币代码和目标货币代码，例如

C:\workspace> java CurrencyConverter 100.50 EUR GBP

应用程序返回源金额转换为目标货币的值例如对于上面的输入，它返回

100.50 EUR = 86.33 GBP

显示转换后的值后程序退出。

可用的汇率（基于 GBP）位于逗号分隔值文件中。这个文件的格式是国家、名称、代码、汇率例如

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

我有一个单独的 java 文件来做这些事情，但我怎样才能将它转换为符合良好 OO 原则的设计良好、可扩展和可维护的形式？

我是否应该考虑任何设计模式，如果可以，需要哪些不同类型的对象/接口以及它们之间的关系？

【问题讨论】：

这个程序看起来足够小，你并不真的需要设计模式。也许是一种检查两种货币之间在线兑换率的方法，然后将其应用于一个数字。
@Rogue 我知道这是一个小程序，因此挑战在于可视化该程序将来可能如何以及以何种方式增长，并因此认为是一个好的设计。关于您检查在线转换的建议，因为提供了 CSV 文件，所以没有必要。
设计模式是解决特定问题的方法，你不能到处问自己一个模式是否适合你拥有的每一段代码。虽然，这在您学习设计模式时很常见。有人称这是一种“疾病”，称为“patternitis”。
如果出现任何新需求的必要性，您总是可以重构程序（可能重构为模式；Joshua Kerievsky 有一本非常好的书“重构为模式”）。不要在项目开始时过度计划和过度优化；大多数情况下，您会遇到其他情况下不会遇到的问题。只需保持代码的可读性和可维护性即可。

标签： java oop design-patterns maintainability object-oriented-analysis

【解决方案1】：

我想到的一些设计方面

读取 CSV 文件：创建 ExchangeRateReader 工厂，以便 各种格式的汇率文件可用作输入。
(Objectify) ExchangeRate POJO 对象包含代码、名称、国家和汇率
具体的 工厂类 生成从 CSV 读取的 ExchangeRate 对象文件
使用 Enum for ReaderType: CVS, TEST, EXCEL //工厂依赖创建适当的实例（具体工厂实例）

【讨论】：