货币转换的设计模式？
我想知道我们是否可以应用设计模式来编写货币转换代码，如果可以，那么它们会是什么？假设转化率是静态的，我们可以对它们进行硬编码。
我考虑过使用“状态模式”，其中每个状态代表一种特定的货币，并将公式封装到相应的转换方法中，例如“toDollars()”、“toPounds()”等。
另一种可能性（不确定它是否是一种设计模式）使用从特定货币转换为另一种货币的函数对象，并将它们作为值存储在二级哈希表中，其中第一级键是“来自”货币，第二级键是“到”货币。
还有其他设计模式可以应用于这个问题吗？最抽象层面的问题是，我们有“m”个实体，并且它们都可以根据某些特定规则进行相互转换。例如，时区值相互转换；不同日历类型（公历/中国）等的日历日期相互转换。
谢谢和问候！
I was wondering if we could apply design patterns to writing code for currency conversion, and if yes then what would they be? The assumption is that conversion rates are static and we can hard-code them.
I thought about using 'state pattern' where every state represents a specific currency and has formulas encapsulated into corresponding methods for conversion, e.g. 'toDollars()', 'toPounds()' etc.
Another possibility (not sure if it's a design pattern) is using function objects that convert from a specific currency to another, and storing them as values in a 2-level Hashtable where the first level key is 'from' currency and the second level key is 'to' currency.
Are there any other design patterns to apply to this problem? The problem at its most abstract level is that we have 'm' entities and they are all inter-convertible based on some specific rules. Examples are converting time zone values in to each other; calendar dates from different calendar types (Gregorian/Chinese) etc. into each other.
Thanks and regards!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
从学习/设计的角度来看，这个问题完全是落后的，因为目标不应该是应用设计模式，而是解决问题并就解决方案进行交流，而设计模式对此有所帮助。
但既然你问了：根据需求，大量的设计模式可能是有意义的：
...
我推荐这个视频：http://www.infoq.com /presentations/Value-Objects-Dan-Bergh-Johnsson
对于这个问题来说有点过分了，但它恰好使用货币转换作为值对象的示例......
From a learning/design point of view this question is totally backward since the aim should not be to apply design patterns, but to solve problems and to communicate about the solutions and design patterns help with that.
But since you asked: Tons of design patterns might make sense depending on the requirements:
...
I recommend this video: http://www.infoq.com/presentations/Value-Objects-Dan-Bergh-Johnsson
It is overkill for the question but it happens to use currency conversion as an example for Value Objects ...
转换是简单的算术，为什么需要花哨的代码结构？
您本质上有一个与货币代码匹配的转换率表（如果您想从任何货币转换为任何货币，而不是从一种货币转换为任何货币然后再转换回来，则可以使用网格）。
从表格或网格中选择正确的比率，并执行简单的除法或乘法（取决于转换的方向）。
不需要设计模式，除非您想要真正喜欢并为每个特定转换（从到对）创建一个类，在这种情况下，您可能会查看一个工厂来根据您提供的货币代码创建这些类的实例工厂。
在工厂上放置一个装饰器或外观，这样您所要做的就是调用一个方法，然后调用工厂并使用结果。
谁知道呢，您可能希望使该外观成为单例，这样您就不必创建多个实例。
但是，对于这个问题来说，所有这些都显得有些过分了，尽管它们可能适合于将转换作为其功能的一部分执行的系统，并且希望通过通用接口（如插件架构）公开不同的计算。
Converting is simple arithmetic, why would you need fancy code constructs?
You've essentially a table of conversion rates matched with currency codes (or grid if you want to convert from any to any rather than from one to any and back).
Select the correct rate from the table or grid, and perform a simple division or multiplication (depending on the direction of the conversion).
No design patterns required, unless maybe you want to get real fancy and create a class for each specific conversion (from-to pair) in which case you might look at a factory to create instances of those classes depending on the currency codes you hand the factory.
Put a decorator or facade over the factory so all you have to do is call a single method which then calls the factory and uses the result.
And who knows, you might want to make that facade a singleton so you won't have to create multiple instances.
But all that would be overkill for this problem, though they might maybe be appropriate in a system that performs the conversion as part of its functionality and wants to expose different calculations through a common interface (like a plugin architecture).
基本上，货币换算是一个图问题，节点对应不同的货币，边对应不同货币之间的换算。通过使用广度优先搜索等方法可以轻松找到最短的转换路径，并且在找到两种货币之间的联系后，您可以在它们之间创建新的直接边缘。为了使图形能够快速处理，您可以单独存储每个节点，并将节点的连接存储在从货币名称到边的映射中。边缘将存储兑换率和指向目标/源货币节点的指针。或者，您可以使用图形的矩阵表示。使用有向图或无向图很容易将其应用于对称和非对称转换。但是，在找到联系后，通过单独计算来实现非对称汇率可能比将它们存储在图表中更好，除非您有所有货币之间的完整转换表。
没有必要比这更花哨，特别是如果你有静态转化率。使用像 toPounds() 这样的函数对所有内容进行硬编码似乎并不明智，除非您的货币很少。像 Convert(int amountInFixedPoint, string fromCurrency, string toCurrency) 这样的 API 更加灵活。
Basically, currency conversion is a graph problem, with nodes corresponding to different currencies and edges corresponding to conversions between different currencies. Finding the shortest conversion path is easy to do by using for example breadth-first-search, and after you find a connection between two currencies, you can create a new direct edge between them. To make the graph fast to process, you could store each node separately and store a node's connections in a map from currency names to edges. Edges would store the conversion rate and pointers to target / source currency nodes. Alternatively, you could use the matrix representation of a graph. It's easy to apply this to both symmetric and asymmetric conversion, using a directed or non-directed graph. However, asymmetric rates are probably better to implement with a separate calculation after finding the connection than with storing them in a graph, unless you have a complete conversion table between all the currencies to start with.
No need to get fancier than that, especially if you have static conversion rates. Hard-coding everything with functions like toPounds() doesn't seem sensible, unless you have very few currencies. An API like convert(int amountInFixedPoint, string fromCurrency, string toCurrency) is much more flexible.