我想不出这个概念的好名字
我只是想要一个融合以下两个想法的类的好名称：
- 交易的“价格” - 项目的 ID 和项目将花费的金额
- 交易产生的“产品” - 项目的 ID 和金额 例如，此类的一个实例
可以包含价格（负 5 个“硬币”），另一个实例可以包含结果（正 2 个“玩具”）。这些对象的集合可以构成一笔交易，为用户删除 5 个硬币并添加 2 个玩具。
我可以创建两个单独的类，即“价格”和“产品”，但除了我无法为组合概念想出一个好名称之外，没有必要这样做。
澄清一下：Transaction 将包含此类实例的任意大小的集合，无论它们涉及价格还是产品。
有什么建议吗？
I just want a good name for a class that merges the two following ideas:
- A "price" for a transaction - an item's ID and the amount the item will cost
- A "product" that results from the transaction - an item's ID and the amount of the item you get
For example, one instance of this class can contain a price (negative 5 'coins') and another instance would contain a result (positive 2 'toys'). A collection of these objects could be made into a transaction which removes 5 coins and adds 2 toys to a user.
I could make two separate classes, Price and Product, but there is no need for this other than I can't think of a good name for the combined concept.
To clarify: a Transaction would contain an arbitrary-sized collection of instances of this class, whether they involve a price or product.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我认为这与在线订购的方式（例如“添加到购物篮”之类的东西）略有相关。也许我正在为您的班级考虑一个类似于购买的名称，它可以保留您班级中购买的数量和产品。
I am thinking that this is slightly related to the way online ordering works like "Add to Basket" kind of stuff. Probably I am thinking of a name similar to Purchase for your class which keeps quantity and the product which is purchased in your class.
您在这里谈论的是订单原型。
订单将商品和服务（由 OrderLines 表示）以及销售交易记录中的各方链接起来。
这些是具有已知属性和关系的已知原型。只要映射清晰，您可以将它们映射到不同的名称。
You are talking about Order archetype here.
An Order links good and services (represented by OrderLines) and Parties in a record of a sales transaction.
These are known archetypes with known properties and relationships. You can map them to different names as long as mapping is clear.
订单或者按照 Sachin 的建议购买怎么样？顺便说一句，“量”通常用于连续的事物（例如气体的量或盐的量）。您可能想要使用术语“数量”，因为它指的是离散的、整数数量的项目。
How about an Order or, as suggested by Sachin, a Purchase? By the way, "amount" is generally used for continuous things (like the amount of gas or amount of salt). You probably want to use the term "quantity" as that refers to a discrete, integral number of items.
您可以简单地将其称为
Element或Item，只要它位于Transaction的命名空间内即可（例如：在 Java 中，将其设为内部类Transaction，这样您就可以将其命名为Transaction.Element）。You could simply call it
ElementorItemas long as its within the namespace ofTransaction(for example: in Java, make it an inner class ofTransaction, this way you can address it asTransaction.Element).单一价格的集合有什么意义？
我宁愿只拥有产品 ID 列表。在结帐时，您获取价格，检查某些产品是否属于“2 的价格 3”类别，或者检查该客户的累积折扣等。
是否具有多个职责的类可能会引入额外的费用您的情况有并发症吗？
What meaning would a collection of sole prices have?
I would rather have a list of product IDs only. In the check-out, you fetch the prices, check if some products fall into '3 for the price of 2' category or check for cumulative discounts for that client, etc.
Can it be that having a class with multiple responsibilities might introduce additional complications in your case?