newbie question: help with polymorphism and/or programming style
sholden at holdenweb.com
Mon Oct 1 17:46:41 CEST 2001
<adina_levin at mindspring.com> wrote in message
news:9p7o8l$4q5$1 at slb2.atl.mindspring.net...
> Hello, Pythonites.
> I am teaching myself python programming, and have created a toy storefront
> If the customer wants to pay with cash, the program should return change.
> the customer wants to pay using a credit card, the program should validate
> the customer's ability to pay, and return an approval.
> Several questions regarding programming style:
> a) Is it desirable to replace the "if" statement in paymenthandler with
> subclasses, PayCash(Payment) and PayCredit(Payment). If so, doesn't that
> just push the "if" statement upstream, where you PayCash() if the customer
> says she wants to pay cash? I am clearly missing something!! :-(
The customer shouldn't need to say whether she will pay cash! See remarks
> b) Is it bad style to return different kinds of information, depending on
> whether the customer pays with cash or credit? If so, how should this be
> handled cleanly?
It is difficult to see how you are planning to use the return values without
the calling code, so this is a tricky one. Generally speaking, however, yes,
it's bad style to have to decode the return type of a function or method to
decide what happened inside the function or method. Frankly I'm having
difficulty deciding why payment *is* an object; more context would help.
> c) Any other programming style problems?
> This is a toy, so no reason to comment on lack of full detail in the
Except that that context it would provide would enable fuller answers, but I
doubt anyone will try to pick nits about that. We're here to help!
> class Payment:
> def __init__(self):
Will a newly-created Customer object do here, or do you later plan to
repalce it with a customer object passed as an argument to __init__()? Or is
Customer not a class at all? The context doesn't make it terribly clear. It
seems that when you create a Payment, it creates (or locates) a Customer,
and sets its own payobject to the result of the cutomer's getpaymentinput()
method. Is this correct?
> def payhandler(self,sum):
> if self.payobject.paytype == "cash":
> print result
Is there a particular reason why you print here but not for credit cutomers?
> elif self.payobject.paytype == "credit":
> return result
So you create a Payment, and then you call the Payemnt's payhandler() method
with the amount of the payment? This seems a little odd, but perhaps makes
sense in the larger scheme of the object model you have designed.
The main problem is that your code doesn't use "polymorphism", one of the
principal principles (;-) of object orientation. Because you don't give much
detail about your approach, all I can do is suggest one possible
alternative. I am sure that other readers will have other, equally valid,
suggestions. You also violate encapsulation, the principle that you
shouldn't have to look inside an object to use it, but we do that all the
time in Python so I wouldn't worry too much about that. We aren't purists
The idea behind polymorphism is that different types of object implement the
same set of operations (methods), so that code which manipulates them
doesn't need to distinguish among the various types of object it must deal
with. You are using an attribute of payobject, which you obtained as the
result of calling a customer method, to determine whether you should process
a cash or a credit payment.
Had you thought of having two different subclasses of Customer, call them
CashCustomer and CreditCustomer? The Customer class would implement all
methods common to both types. Both CashCustomer and CreditCustomer would
inherit these common method from Customer, and each would provide an
appropriate ProcessPayment(amount) method. E.g.:
pass # a simple implementation!
def ProcessPament(self, amt):
if self.cashonhand >= amt:
self.cashonhand -= amt
raise CannotPay, "customer only has %f" % self.cashonhand
def ProcessPayment(self, amt):
raise CannotPay, "card issuer will not allow payment of %f" %
The advantage of such an approach is that anywhere in your code where you
are dealing with a Customer (of either type) c, you can call
c.ProcessPayment(x) to resuest a payment of amount x, and expect to raise an
exception of the payment cannot go through for whatever reason. Hence my
assertion that your code "shouldn't need to know the type of customer".
If you're new to OO this may be confusing, and I emphasise it's only one of
many possible approaches. I hope it helps you to realise that Python code
can be extremely clean when you do things right. Exceptions can help
simplify logivc when you want to concentrate primarily of the case where
everything goes right, but nevertheless have to accept that sometimes things
will go wrong.
More information about the Python-list