Le mercredi 4 septembre 2013 09:44:27 UTC+2, Gildor Oronar a écrit :
> Thanks:
>
>
>
> El 04/09/13 05:01, Terry Reedy escribió:
>
>
>
> > I would expect that every account class has a transaction method.
>
> > * If so, just call it, but
>
> > assertIsNot(DebitAccount.transaction, AbstractAccount.transaction)
>
> > for every subclass in your test suite.
>
> > * If not, perhaps you need an abstract subclass TransAccount. Then use
>
> > hasattr in production code and the isnot test in test code.
>
>
>
> I would assume that you categorize this as a unit test problem, because
>
> you consider an Acount not implementing Transaction is a bug, right?
>
>
>
> There are two occassions an account is intended not having Transaction
>
> function, both not test-related:
>
>
>
> 1. The acount doesn't offer this feature. e.g. Certificate of Deposit.
>
> This can be in TransAccount.
>
>
>
> 2. The 3rd-party account offer this feature but doesn't qualify the
>
> software's requirement, e.g. not returning the result in 3 seconds, and
>
> is avoided when planning the deal (I am writing an auto-trade software).
>
> This case you cannot categorize those who can into TransAccount,
>
> beacause 1) that naming imply other accounts don't do transaction but
>
> they do, just not good enough; 2) when other accounts becomes good
>
> enough, the change (to inheritance) is a bit too invasive.
Hello,
and what about something like that :
class AbsctractAccount():
def transaction(self, amount, target):
logging.info("Start transaction of %s to %s" % (amount, target))
self.DoTransaction(amount,target)
def DoTransaction(self,amount,target):
pass # or raise notimplemented or do not implement this methods in the
abstract class
...
class DebitAccount(AbstractAccount):
def DoTransaction(self, amount, target):
...
class SomeOtherAccount(...)
....
like that you only have to write the logging function once.
--
https://mail.python.org/mailman/listinfo/python-list
