Hi Steve,
"Steve" == Steve Alexander <steve@cat-box.net> writes:
>> ShopperManager.InsertItemIntoShoppersBasket(shopper=aShopper, >> mi=aMarketItem, quantity=qty), Steve> Seeing as the context is clearly ShopperManger (or Steve> Shoppers), I don't think there's any need for such a long Steve> method name. The context clearly involves shoppers and Steve> baskets, so perhaps AddToBasket(shopper, item, qty) would Steve> be clear enough? Yeah.. the long method name was to help clarify the meaning. ;-) Steve> If anything, AddToBasket could be a method of MarketItem. Steve> Item.addToBasketOf(Shopper). However, if Items live on Steve> Shelves in Isles in a Shop, addToBasketOf could be a method Steve> of the Shop, that gets found by acquisition from items in Steve> the shop. And, perhaps we know who the Shopper is from the Steve> AUTHENTICATED_USER of the REQUEST. Again... it seems to me that these objects aren't allowed to have methods, since that would require sub classing and according to my understanding sub classing is sort of a 'deprecated' approach. Maybe I'm missing something... I like your thought about the 'shop' being the best object responsible for handling the shopping baskets.. it's just a different way to slice the problem.. I could get used to it. ;-) thanks, -steve