When thinking about the ShippingMethod class we talked about the importance of designing immutable classes thus allowing us to create constant objects and reuse them freely. Also while trying to identify the relationships to the SurvivalKitOrder class in order to dispatch it we hold back from defining a rather complicated one.
Now the ShippingMethod is your point of reference. It's what you can reuse again and again to dispatch (Hint) an order to an address. The SurvivalKitOrder and the Address is what varies each time. So whenever a new purchase is made, you choose the ShippingMethod and create a new SurvivalKitOrder and an Address.
Designing for reusability through constants is "the key to success". If you look back at the design of your classes you will come to realize that not only you have defined the minimum required relationships between them but in doing so you have effectively avoided any concurrency issues in the process.
The reason for that is that any shared objects (the shipping method) are constants and anything that varies (order, address) is new to each thread.
The question that remains is where do you create a new order and an address and how does it all come together? That's where the controller steps in. The controller itself could be mapped to a URL that handles purchases and gets all the address details from the form.
This effectively also closes the circle for the #purchase method which has now found its place.
Next in the series is "Honour Your Builders" where we'll see how you can go on creating survival kits the fun way. Don't miss it.
Disclaimer: This is example code to make you think of class relationships and reusability. The ShippingMethod#dispatch will most likely require some other class relationship to do the dispatch, so in the real world you'll might have to take that into consideration as well.