I can't think of a good name for this concept

I just want a good name for a class that merges the two following ideas:

1. A "price" for a transaction - an item's ID and the amount the item will cost
2. 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 开发者_JAVA百科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?

---

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.

---

You are talking about Order archetype here.

The Order archetype represents a record of a request by a buyer for a seller to supply some goods or services.

An Order links good and services (represented by OrderLines) and Parties in a record of a sales transaction.

The OrderLine archetype represents part of an Order that is a summary of particular goods or services ordered by a buyer.

These are known archetypes with known properties and relationships. You can map them to different names as long as mapping is clear.

---

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.

---

• ProductTransaction
• ProductTransactionResult
• NerfHerder

---

You could simply call it Element or Item as long as its within the namespace of Transaction (for example: in Java, make it an inner class of Transaction, this way you can address it as Transaction.Element).

---

a Transaction would contain an arbitrary-sized collection of instances of this class, whether they involve a price or product

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?