The Shopping Cart and Order Classes

I l @ ve RuBoard

The Shopping Cart and Order Classes

Looking back on the initial list of classes captured from the mission statement, it looks like everything with the exception of three classes has been modeled ”the shopping cart, the order, and promotions. Let's hold off on promotions until the detailed use cases are done, but let's consider the shopping cart and order classes now.

A shopping cart is a list of products that the customer has placed into his basket , whereas the order is the shopping cart once the customer has decided to actually purchase the items. In some ways, they're very different. A shopping cart is temporary, meaning that it might not persist beyond the current session. An order is forever, and it needs to be stored and available at any point in the future for fulfillment and auditing.

In other ways, they are similar. Both store lists of products and quantities , both need to do calculations to figure out the current balance, and so on. In fact, they are so similar that you can use the same classes to store information for both purposes. So, although there will be an order object that stores information specific to orders, it will use the same shopping cart object to store the actual contents of the order.

At this point, an interesting subtlety occurs. Orders need to be snapshots of the information in place at the time the order was taken. This means that, as much as you might like to have the order point to the address and credit card objects that were used to place the order, they might be edited or removed by the customer after the date of purchase. As a result, you need to actually duplicate that data in the database for explicit storage. You'll do this by creating new address and credit card objects to hold the values as they were at the time the order was placed (see Figure 5.6).

Figure 5.6. New address and credit card objects hold the values when an order is placed.

The same goes for products ”the price might change, as might the product description. The order object needs to hold the user 's ordered products as they were the day they were ordered. How are you going to do this? The practical answer is to reuse the product objects to store the unique products that a customer purchased, but then to store them in a different table in the database. This might sound a bit confusing, but it will be clearer once you start coding.

I l @ ve RuBoard