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
