Hi Steven Not quite. From the catalogue I want to see what is in the user's cart. As they browse the catalogue they will see a flag next to each item if it is in the basket; 'n already in your basket' sort of thing.
So from the class which produces catalogue pages I want to be able to obtain information about the contents of this user's basket. You may say, instantiate the basket class from the catalogue class and in many ways this seems the simplest. I haven't done this because the both classes are part of a framework. Basket does not have a constructor of its own but a method which constructs it as part of the framework - I think what I probably need is to create a new class which both these can use. Thanks for all your help Justin Steven Siebert wrote: > > If I am reading your situation correctly, you want to be able to > reference the catalogue for product information from the cart? > > 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. > > Regards, > > S > > On Thu, Jan 29, 2009 at 2:11 PM, kropotkin <enquir...@mms-oxford.com> > wrote: >> >> Hi Steven >> >> The method doesn't effect the state of anything . It just returns some >> information. The context is: >> 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! >> >> Regards >> >> Kropotkin >> >> >> >> >> >> Steven Siebert wrote: >>> >>> It depends. (always the expected answer with an OOP design question =) >>> >>> Generally, if the method you are calling on class A does not work >>> on/effect the state of a specific object, its a canidate to be a >>> static (class) method. However, you should be careful about coupling >>> your objects and understand what you are doing when you do. If you >>> feel comfortable for that method be a static method, though, you're >>> probably good to do so. Generally....depending.... >>> >>> =) >>> >>> Hope this helps. >>> >>> Steve >>> >>> On Thu, Jan 29, 2009 at 12:54 PM, kropotkin <enquir...@mms-oxford.com> >>> wrote: >>>> >>>> Hi >>>> >>>> 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 >>>> >>>> Thanks >>>> >>>> Justin >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Class-method-or-Object-method--tp21732172p21732172.html >>>> Sent from the mod_perl - General mailing list archive at Nabble.com. >>>> >>>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Class-method-or-Object-method--tp21732172p21733697.html >> Sent from the mod_perl - General mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Class-method-or-Object-method--tp21732172p21735936.html Sent from the mod_perl - General mailing list archive at Nabble.com.
