On Thu, 29 Jan 2009, Steven Siebert wrote: > On Thu, Jan 29, 2009 at 2:11 PM, kropotkin <enquir...@mms-oxford.com> wrote: > > class A is the Catalogue and B is the Cart. Usually they > > are separate but I want to show a flag relating to the > > basket/cart in the catalogue against each product. > > Really I am putting the method in the Cart class because > > it seems to logically belong there - for organisational > > reasons. I see what you mean about coupling though. It > > could get messy! > >>> > >>> In general is it better to use a class method or > >>> object method? E.g I have a class A which provides > >>> certain functionality. I just want to use one of its > >>> methods in another class B. Is it better to > >>> inistantiate class A and do and object call or just do > >>> A->myMethod() ? The method doesn't need a reference to > >>> itself passed in so from that point of view it doesn't > >>> matter > > If this is the case, perhaps the cart should be a > container for "PurchaseItem" objects which contain the > essential data (ie price, weight) and behaviours > (calcShippingCost(), calcTax(), getProductInfo() - the > last which can pull the reference from your catalogue). > Additional information about the PurchaseItem can be "lazy > loaded" from the catalogue if needed (ie product > description) to keep your PurchaseItem lite and > purpose-oriented. As an added bonus, by containing the > PurchaseItems within the cart you can easily provide > convience methods to iterate over the collection for > things like calculating the total weight, total price, > etc.
Yes, it seems like from the perspective of a mod_perl handler (this is the modperl list after all) that doing these as objects would be better. Especially the cart, but also the catalog, because you don't know if they'll ask you to run another catalog using the same structure. Class function calls should not be used for request-specific data that persists, i.e. data stored in package scope, especially in mod_perl, e.g. your cart contents. Because the class scope data persists across requests, so it can get confusing trying to sort out things if another customer gets the next request. Objects are useful because they form discrete containers of data in the blessed references that represent unique entities of a particular class, and they (typically) would not persist across requests unless you use a persistent object storage mechanism that keeps them straight. Cognitively, a catalog should not contain the cart. Maybe your application should be a sort of "view" controller that contains references to both the catalog object (source of product data) and the cart object (contains items they bought). view object / \ catalog cart Then, the view selects what items to display, and asks the cart if it contains those items when deciding whether to display the flag. Mark